Certain subsonic API calls are missing authorization headers

Support
1

Issue description:

Hi, I am running Navidrome as my music server which is sitting behind caddy and authentik forward auth. I have noticed that, since moving to authentik, my media information in Symfonium is unknown. Seems to me that this is the same issue as Codec / bitrate Unknown and I believe it to be a bug within Symfonium rather than an issue with the reverse proxy/authentik. I have uploaded my symfonium logs and also an excerpt from my reverse proxy and authentik. I believe the relevant error here is the “FFProbe.. no media information extracted…” error; you will notice that these requests receive a 404 from my authentication backend, but I am able to access them on my browser with no issues with the appropriate authentication cookie set. I have noticed that all the offending requests have the user agent “lavf/60.16.100” which definitely seems incorrect - the requests which have the Symfonium user agent seem to authenticate just fine. Possibly, this issue may be related to Wear OS: Application does not playback/download music - for what it’s worth I tried the approach suggested in that thread whereby I use custom authorization headers but that results in the same behaviour.

Please let me know if more information is required.

P.S. Unrelated to this issue, but would it be possible to implement caching the authentication cookie returned when using proxy authentication? Currently, every single request must be authenticated which results in a significant performance hit (related: Header authentication | authentik ).

Many thanks.

Logs:

Upload description: kojak

Additional information:

See main issue description.

Reproduction steps:

N/A

Media provider:

Subsonic

Screenshots:

See Codec / bitrate Unknown

2

The useagent is correct it’s ffmpeg one. Usually the headers are lost when there’s a redirect at some point.

3

Any idea where the redirect may be coming from?

4

You know your network stack not me.

Custom headers are sent via ffmpeg too you can probably verify the first thing that answer on the configured url and port.

5

Fair, I will keep digging.

6

To follow up - what ffprobe command is Symfonium running exactly? I can confirm, running on my local machine, when running “ffprobe URL” I get the exact same error “Invalid data found when processing input” but when running “ffprobe URL -headers “Authorization: Basic …” the command completes successfully. I cannot see any redirects happening and it does look like it is a problem with Symfonium (could be wrong ofc)…

7

Don’t you have logs on the proxy to see what headers are sent ? That’s the only way to know for sure. Specially when you said you tried the workaround to use custom headers and not auth headers.

The headers are sent for sure, maybe ffmpeg modify them or there’s some special character not properly escaped, those are not logged for privacy so I can’t guess without you debugging your stack too.

8

Well that’s what I’m saying, the proxy (judging from the logs) is not receiving the header but when I run ffmpeg with the same URL on my machine with the -header option, it works fine hence why it seems to me that this is a symfonium bug.

9

The headers are sent this is the docker nginx I use for the validations

server {
    listen 8080;
    listen [::]:8080;
    server_name _;

    location = / {
        return 302 /navidrome/;
    }

    location = /navidrome {
        return 301 /navidrome/;
    }

    location /navidrome/ {
        # Nginx may join repeated request headers as a comma-separated string.
        # Validate against the first header value to avoid false negatives.
        set $authorization_first $http_authorization;

        if ($http_authorization ~ "^\s*([^,]+)\s*,") {
            set $authorization_first $1;
        }

        if ($http_authorization = "") {
            return 401 "Missing required header: Authorization\n";
        }

        if ($authorization_first != "Basic ${REQUIRED_BASIC_AUTH_B64}") {
            return 401 "Invalid basic auth credentials\n";
        }

        proxy_pass http://navidrome:4533;
    }
}

And everything works as intended.

10

Ok, that is helpful, thanks.. I will continue debugging.

11

Following up - just wanted to let you know that you were correct and I was wrong (definitely not a bug in Symfonium) :upside_down_face:

The issue was that ffmpeg uses host:443 rather than just an implicit https address and these requests were being dropped by authentik - easy fix at the reverse proxy side.. Apologies if I wasted your time and thanks for your input.

On a side note, any chance you would implement, sometime in the future, caching the session cookie to prevent every request from being authenticated individually?

Thanks.

12

I can’t there’s different tools involved and manually handling cookies between them for an ultra specific out of normal usage scope is totally not worth it sorry.

13

No problem, that is understandable, thanks.