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!