Sub sub domain user access control with docker labels

[marcus-k]

Hello,

How are sub sub domains (i.e. tinyauth.sub.domain.com) to be used with access control? Reading the documentation I just cannot get any user access control working with sub sub domains. I am assuming i need to set the tinyauth.apps.myapp.domain labels somewhere? But unfortunately it is not very clear where to do this or if this is actually the right path for this. Any help would be great!

[steveiliop56]

As long as you use tinyauth.sub.domain.com in your APP_URL everything should work. For labels you could use either tinyauth.apps.foo.bar: foobar (where the foo matches with foo.sub.domain.com) or set it explicitly, so tinyauth.apps.whatever.config.domain: foo.sub.example.com. If you face any issues with v4, please try with v4.0.1-alpha.1 because there is a bug in v4 with label discovery.

[marcus-k]

I just tried with the latest release of v4.0.1 but have had no luck. Perhaps I am misunderstanding its usage.

As an example, I have a container exposed to foo.sub.example.com. In its docker compose I added the label:

labels:
  tinyauth.apps.foo.users.allow: testuser1

Then, logging in as a different user, say testuser2, I am still able to access the container webpage despite the label. I also tried specifically blocking testuser2 with the label but that didn't work either. I double-checked that /var/run/docker.sock was mounted in the tinyauth service too.

I also tried setting in the container

labels:
  tinyauth.apps.foo.users.allow: testuser1
  tinyauth.apps.foo.config.domain: foo.sub.example.com

but this doesn't stop me from logging in as the other user as well.

[steveiliop56]

Can you share the logs of Tinyauth in debug mode?

[marcus-k]

The debug mode certainly helped out. It reported that there was permission errors accessing the docker socket. It turned out the issue was the user: "1000:1000" I added in the docker compose file to set the user so that the database file tinyauth created wouldn't be owned by root. Didn't cross my mind that there would be permission issues with the Docker socket. Removing this line fixed the permission error, though it would be great to have the database have a different user, perhaps with PUID and GUID environment variables!

[ccxuy]

2026-02-26T17:16:33Z DBG internal/middleware/zerolog_middleware.go:69 > Request address=127.0.0.1:47492 client_ip=127.0.0.1 latency="156.384µs" method=GET path=/api/healthz status=200

2026-02-26T17:16:43Z WRN internal/service/auth_service.go:130 > Local user not found username=user

2026-02-26T17:16:43Z DBG internal/controller/proxy_controller.go:70 > Request identified as (most likely) coming from a browser

2026-02-26T17:16:43Z DBG internal/service/docker_service.go:70 > Docker not connected, returning empty labels

Config={"Domain":""} IP={"Allow":null,"Block":null,"Bypass":null} OAuth={"Groups":"","Whitelist":""} Path={"Allow":"","Block":""} Response={"BasicAuth":{"Password":"","PasswordFile":"","Username":""},"Headers":null} Users={"Allow":"","Block":""}

2026-02-26T17:16:43Z TRC internal/controller/proxy_controller.go:88 > ACLs for resource acls=

2026-02-26T17:16:43Z DBG internal/service/auth_service.go:421 > IP not in bypass list, continuing with authentication ip=

2026-02-26T17:16:43Z DBG internal/service/auth_service.go:404 > IP not in allow or block list, allowing by default ip=

Email= IsLoggedIn=true Name=User OAuth=false OAuthGroups= OAuthName= Provider=username TotpEnabled=false TotpPending=false Username=user

2026-02-26T17:16:43Z TRC internal/controller/proxy_controller.go:156 > User context from request context=

2026-02-26T17:16:43Z DBG internal/service/auth_service.go:305 > Checking users

2026-02-26T17:16:43Z INF internal/middleware/zerolog_middleware.go:66 > Request address=:47838 client_ip= latency=1.572848ms method=GET path=/api/auth/traefik status=200

2026-02-26T17:16:44Z WRN internal/service/auth_service.go:130 > Local user not found username=user

2026-02-26T17:16:44Z DBG internal/controller/proxy_controller.go:72 > Request identified as (most likely) coming from a non-browser client

2026-02-26T17:16:44Z DBG internal/service/docker_service.go:70 > Docker not connected, returning empty labels

Config={"Domain":""} IP={"Allow":null,"Block":null,"Bypass":null} OAuth={"Groups":"","Whitelist":""} Path={"Allow":"","Block":""} Response={"BasicAuth":{"Password":"","PasswordFile":"","Username":""},"Headers":null} Users={"Allow":"","Block":""}

2026-02-26T17:16:44Z TRC internal/controller/proxy_controller.go:88 > ACLs for resource acls=

2026-02-26T17:16:44Z DBG internal/service/auth_service.go:421 > IP not in bypass list, continuing with authentication ip=

2026-02-26T17:16:44Z DBG internal/service/auth_service.go:404 > IP not in allow or block list, allowing by default ip=

Email= IsLoggedIn=true Name=User OAuth=false OAuthGroups= OAuthName= Provider=username TotpEnabled=false TotpPending=false Username=user

2026-02-26T17:16:44Z TRC internal/controller/proxy_controller.go:156 > User context from request context=

2026-02-26T17:16:44Z DBG internal/service/auth_service.go:305 > Checking users

2026-02-26T17:16:44Z INF internal/middleware/zerolog_middleware.go:66 > Request address=:47838 client_ip= latency=4.232881ms method=GET path=/api/auth/traefik status=200

2026-02-26T17:16:53Z WRN internal/service/auth_service.go:130 > Local user not found username=user

2026-02-26T17:16:53Z WRN internal/service/auth_service.go:130 > Local user not found username=user

2026-02-26T17:16:53Z INF internal/middleware/zerolog_middleware.go:66 > Request address=172.18.0.6:60298 client_ip=119.123.52.34 latency="162.271µs" method=GET path=/api/context/user status=200

2026-02-26T17:16:53Z INF internal/middleware/zerolog_middleware.go:66 > Request address=172.18.0.6:60310 client_ip=119.123.52.34 latency="272.018µs" method=GET path=/api/context/app status=200

  tinyauth:
    container_name: tinyauth
    image: ghcr.io/steveiliop56/tinyauth:v4
    restart: unless-stopped
    networks:
      - proxy
    ports:
      - "<removed>:3000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - <removed>/tinyauth/data:/data
    labels:
      - com.centurylinklabs.watchtower.enable=true
      - traefik.enable=true
      - "traefik.http.routers.tinyauth.rule=Host(`<removed>`)"
      - traefik.http.middlewares.tinyauth.forwardauth.address=http://tinyauth:3000/api/auth/traefik
      - tinyauth.apps.whoami.oauth.groups=xiaohuoche
    environment:
      - LOG_LEVEL=trace
      - APP_URL=<removed>
      - USERS=<removed>
      - SECRET=<removed>
      - LDAP_ADDRESS=ldap://lldap:3890
      - LDAP_BASE_DN=<removed>
      - LDAP_BIND_DN=<removed>
      - LDAP_BIND_PASSWORD=<removed>
      - PROVIDERS_POCKETID_CLIENT_ID=<removed>
      - PROVIDERS_POCKETID_CLIENT_SECRET=<removed>
      - PROVIDERS_POCKETID_AUTH_URL=https://<removed>/authorize
      - PROVIDERS_POCKETID_TOKEN_URL=https://<removed>/api/oidc/token
      - PROVIDERS_POCKETID_USER_INFO_URL=https://<removed>/api/oidc/userinfo
      - PROVIDERS_POCKETID_REDIRECT_URL=https://<removed>/api/oauth/callback/pocketid
      - PROVIDERS_POCKETID_SCOPES=openid email profile groups
      - PROVIDERS_POCKETID_NAME=Pocket ID
      
  whoami:
    image: traefik/whoami:latest
    container_name: whoami
    restart: unless-stopped
    networks:
      - proxy
    ports:
      - "<removed>:80"
    labels:
      - traefik.enable=true
      - traefik.docker.network=proxy_default
      - "traefik.http.routers.whoami.rule=Host(`<removed>`)"
      - traefik.http.services.whoami.loadbalancer.server.port=80
      - traefik.http.routers.whoami.middlewares=tinyauth
      - tinyauth.apps.whoami.config.domain=<removed>
      # - tinyauth.apps.whoami.oauth.groups=admin
      - tinyauth.apps.whoami.users.block=user

I have the same issue, ACL is not working

[ccxuy]

It seems like tinyauth is not getting any label from the target container @steveiliop56

[steveiliop56]

Tinyauth reports it cannot connect to the docker socket. Are you maybe using docker rootless or podman?