Basic Auth Passthrough with NPM/Nginx Proxy Manager

[kramttocs]

I know there is an example using labels for traefik but can this be accomplished with NPM?

[kramttocs]

1. Adding labels to the service compose itself - no problem
2. What about this that appears traefik specific? traefik.http.middlewares.tinyauth.forwardauth.authResponseHeaders: authorization
3. When using docker-socket-proxy (great suggestion - using it already with WUD), is CONTAINER all that is needed?
   --Looks like it should be since labels come back in xxxxxx:2375/containers/json
4. What if we have multiple hosts running docker-socket-proxy. Can we add multiple DOCKER_HOST entries like DOCKER_[hostname]_HOST ?

[steveiliop56]

1. Labels can work with every reverse proxy as long as Tinyauth can see them, so you should be fine. In case NPM is not running in the same host as Tinyauth you could even add the labels on the Tinyauth container itself.
2. Yes, this is only specific to Traefik. It just tells it to forward the authorization header from the authentication server. In NPM you will probably need to do add something like:

auth_request_set $tinyauth_auhtorization $upstream_http_authorization;
proxy_set_header authorization $tinyauth_authorization;

3. IIRC yeah, Tinyauth only needs to be able to see the labels from other containers, if it can, it should work.
4. This is not supported no. If you need multiple hosts you can just add the labels to the Tinyauth container itself and they should work just fine.

[kramttocs]

Thanks!
To make sure I understand vs just doing it - on #4 all those are for is to store the u/n and pwd values? When tinyauth gets the request to auth (redirect from npm in my case), it grabs the subdomain from the request, looks for a matching label and then returns those values in the response auth header?

I am sure this has been covered but is there any benefit to using the socket or does it make more sense to just add the labels to tinyauth?

[steveiliop56]

Yes, that's how Tinyauth works. It extracts the last part of the domain (e.g. it will use app1-foo from app1-foo.bar.example.com as the app name) and it will look up the labels based on this. You will need the socket in both cases, so even if you add the labels on the Tinyauth container, it's going to need the socket to read them from itself.

[kramttocs]

Not sure what I am missing, well probably a lot, but not getting it to work. It takes me to tinyauth but then redirects me back (after authenticating) and I still get the basic popup.

Worth noting that the site automatically redirects from / to /gui . I tied changing the location / to be /gui but still getting the basic prompt.

[steveiliop56]

This means that Tinyauth is probably working correctly and the basic pop up is from the protected app. This part of the documentation may help you.

[kramttocs]

Thanks - that's the doc I followed and yes it's possible tinyauth is working but I haven't yet found a way to confirm that it really is sending the basic auth header back.

Spent too long on it last night so will let it sit for awhile and then revisit. :D

[gmsiegel]

I'm running into the same issue. I have a basic auth app I'd like to protect with TinyAuth (and Pocket ID). I first connect to TinyAuth and select the Pocket ID option, which redirects to Pocket ID for a passkey sign-in. It then sends me along to the web app, but the username & password login still page appears- it's not passing along the credentials. I have them setup as environment variables in my Docker Compose file (Docker Container name is "UPTIMEKUMA"):

      - TINYAUTH_APPS_UPTIMEKUMA_RESPONSE_BASICAUTH_USERNAME=(redacted)
      - TINYAUTH_APPS_UPTIMEKUMA_RESPONSE_BASICAUTH_PASSWORD=(redacted)

Not sure where to put these lines in the NPM Advanced section with the TinyAuth code:

    auth_request_set $tinyauth_auhtorization $upstream_http_authorization;
    proxy_set_header authorization $tinyauth_authorization;

[steveiliop56]

@gmsiegel you should add the authorization header lines below the error_page 401 = @tinyauth_login; directive.