Enquiry about tempus' authentication

[dragon-slayer875]

Hello.
I wanted to ask what authentication mechanisms tempus uses to authenticate with the servers.
I am going to be securing my navidrome instance using authelia's reverse proxy authentication and was wondering if tempus supports the same, i.e, backends behind reverse proxy authentication.

[eddyizm]

Hi @dragon-slayer875 So generally speaking, it uses the subsonic/opensubsonic api - in previous tests I've had with my backend (LMS) you just need to make sure you enable the proxy headers on the app (LMS in my case) so it looks for them and make sure your reverse proxy is forwarding the headers - the app should not care or know any better.

[eddyizm]

the basic auth option that @LucaTony has mentioned in the other app, since its not foss, i can't see what they are doing. but we could test it, maybe i could get a test account on your server so I can test that code to see if i can login with my emulator?

[dragon-slayer875]

I see. I'll set up a test account for you. How would you like to receive the credentials?

[eddyizm]

I have a contact form on my website or dm in my fosstodon (see profile) or send me an email at my username [at] gmail

[dragon-slayer875]

Sent creds on email.

[eddyizm]

Sent creds on email.
Got it thanks!

[LucaTony]

Coming from #15 , since coincidentally this discussion is actually what I meant there. I'm trying to get auth with reverse-proxy with subsonic (https://www.navidrome.org/docs/usage/reverse-proxy/#subsonic-endpoint) to work but I get 401 error when trying to connect.
I am forwarding the following headers with caddy:
copy_headers Remote-User
copy_headers Remote-Email
copy_headers Remote-Name
copy_headers Remote-Groups
. In the webapp it's working. Should this also work with tempus? With the symfonium it worked by checking the basic auth option.

[dragon-slayer875]

@eddyizm it still doesn't seem like authelia is receiving the credentials.
May I ask how you have implemented basic auth?

UPDATE: Might have found the problem. I'll research a bit more and report back.

[eddyizm]

@dragon-slayer875 sorry, i forgot we did not link back to the original PR.
https://github.com/eddyizm/tempus/pull/15/files is what I added to the code base -> I was not really able to test this because I didn't have anything set up to verify it works. I have doubts this works for sso IMO but some of the info/links @LucaTony provided did point to it. It does look like it should respond with a basic auth header when challenged from the server. (see caddy's basic_auth)

[LucaTony]

@dragon-slayer875 @eddyizm OK I also tried the dev build but without success. I compared the symfonium and tempus request in the caddy log and the relevant difference seems to be the authorization header of basic auth (not sure about the cookie). I was able to reproduce it with a manual REST request to the auth api and it doesn't even redirect it is straight 200 with the response of navidrome when including the headers.
Here an excerpt of the first symfonium request:
,"uri":"/rest/ping.view?u=luca&t=asdf123&s=aaasdf123&v=1.13.0&c=Symfonium&f=json","headers":{"User-Agent":["Symfonium/13.5.0b (Linux;Android 16)"],"Authorization":["REDACTED"],"Set-Cookie":["REDACTED"],

[dragon-slayer875]

Apologies being MIA. Was in talks with Authelia guys to get a Caddy related bug fixed.
@eddyizm similar to @LucaTony I also can't see any Authorization header being sent in the request from tempus to caddy.
Note: Tempus should not wait to be challenged to send the Authorization header. It should send it along with the login request itself.

This is how the auth header should look

[eddyizm]

Apologies being MIA. Was in talks with Authelia guys to get a Caddy related bug fixed. @eddyizm similar to @LucaTony I also can't see any Authorization header being sent in the request from tempus to caddy. Note: Tempus should not wait to be challenged to send the Authorization header. It should send it along with the login request itself.

This is how the auth header should look

yeah, that is what it is doing. It is the way basic auth actually works, which i believe this is why it was implemented this way. Adding basic auth to a web server, protecting a route, I imagine it would work as this does not even have a setting, will just negotiate.

I will test something different to force and send it across directly, if it works, we can figure out what we want to call it and how to handle it in the app.