Pass Basic Auth Username and Password Headers

[stalinCCCP415]

Is it possible to have tinyauth pass basic auth headers? I think it is with the documentation I’m reading for 3.4.0 but I’m a bit out of my depth.

I’m looking for a successful login to pass basic auth headers with a defined username and password to the app. Is this possible? Can you provide an example?

[steveiliop56]

Hello!

By basic auth headers you mean pass an Authorization header or the Remote- headers?

[stalinCCCP415]

Yes I believe so 😅. Basically if a website is using http basic login (the pop up with username and password) I'd like to be able to pass that with a successful tinyauth login.

[steveiliop56]

Never thought of that, it could be a useful feature. Can you open an issue for it so I don't forget?

[stalinCCCP415]

Will do! This is an example of the feature I'm referring to: https://docs.goauthentik.io/docs/add-secure-apps/providers/proxy/header_authentication

[bfpimentel]

Continuing here the discussion for #212 (reply in thread) (I was actually in the wrong discussion).

I managed to make it work so I'm going to write a little guide here for those who wish to implement it before the documentation gets updated.

1. Use nightly
2. Pass through the docker socket
3. Add the labels for basic auth:
   3.1. tinyauth.basic.user and
   3.2. tinyauth.basic.password
4. If using Traefik, add the Authorization entry to the auth.forwardauth.authResponseHeaders.

[bfpimentel]

@steveiliop56 I haven't seen the docker socket configuration mentioned in the documentation anywhere. Even though it's obvious when talking about labels, I think it's good to have it documented.

In anyway, I believe search functionality in the wiki would be greatly appreciated.

[steveiliop56]

@bfpimentel I know. I am currently reworking the tinyauth website so it may take some time to add everything (a lot of new things in v3.5.0) but I will for sure include everything.

[bfpimentel]

@steveiliop56 I'm sorry for resurrecting this topic once again but I think it's for the best.

As I've mentioned above, I managed to make it work and I'm happy with it, but I'd like to make a suggestion that would enhance the current implementation. I could even try to make a PR for that.

gethomepage.dev has a templating feature for using secrets in environment variables.

So, we would use like {{TINYAUTH_VAR_RADARR_PASSWORD}} as the tinyauth.basic.password value in a given container (Radarr as example) and provide TINYAUTH_VAR_RADARR_PASSWORD for the Tinyauth container.

This would avoid hardcoding the basic auth credentials. Although in most cases for self hosted environments this wouldn't be an issue, it still a bad practice to have credentials hardcoded.

What do you think?

[steveiliop56]

Hello!

Although this would be cool it's hard to implement and a bit a of niche feature. I believe you can achieve almost the same thing with an environment file and then use ${TINYAUTH_RADARR_PASSWORD} in the labels. Although I will probably implement a tinyauth.basic.password.file label so as you can store your secrets as files.

[bfpimentel]

Well... This also works. And a lot less engineered than what I proposed. Looking forward to seeing the .file label prop.

I'll test with your suggestion. I've tried with $TINYAUTH_RADARR_PASSWORD before but didn't have success - maybe the escaping was wrong in my end.

[bfpimentel]

Update: Using the env variable directly in the label value might work but I won't be able to test it accordingly because I'm using Nix to define my containers.

So, I'll need to wait for the .file prop.

Thank you for the promptness and the kindness in your answers.