Maybe I have incorrectly assumed here but I was expecting Symfonium to use the custom headers I add for all communications back to the media provider. In my testing however this seems not to be the case which is causing my proxy to return 404 errors.
Logs:
Upload description: kelvin
Additional information:
Additionally special characters are not supported it would seem in the custom headers which is inconsistent with other applications, more of a niggle but the lack of clear documentation on this whole process makes it a barrier to adoption and recommendation.
Reproduction steps:
Configure proxy and ensure no custom headers are required. Add a media provider into Symfonium and sync. Add custom header configuration into proxy and restart the service. Update the media provider in Symfonium to include the newly required custom headers and this will generate a failure. The solution I have found is to add the custom headers into the Symfonium media provider before adding them into the proxy configuration, this infers an out of sequence validation check of the media provider which does not honour the custom headers added into the configuration.
The initial setup of Jellyfin does not allow advanced configuration because it makes the process a lot more complicated for the 99,999999% of users who don’t need it.
But if you edit the provider then save the settings the headers will be sent for everything.
Your log extract from the proxy have 0 details and does not show why it returns 404 (Hint: It should not if it requires headers for auth) so it’s probably something wrong with the headers you use how they are encoded to respect the RFC and what the proxy does.
If I may add a note too: You write that the log description is Upload description: kelvin yet the description you used is :
This could just be a documentation/process issue but I've found 2 concerns on the road to fixing this.
1. I don't believe you allow/support special characters in the custom header?
2. I needed to add the custom header values into the media provider before setting them in my Traefik proxy configurations. I'm inferring from this there is a provider validation check necessary before the custom headers are honoured. Is this also why you don't allow custom headers to be specified when first adding a media provider?
Either way this was a clunky process which could be a lot simpler and as a minimum have some easily findable and clear documentation. Please do correct me where I've made an error, I would appreciate the feedback. Thank you.
I got a little confused with the support request process on where to add details so my apologies if what I put and where I put it is a little confusing.
The process I was working towards was to configure Symfonium to use custom headers so as to be successfully routed by my Traefik proxy. I typically use authelia for 2FA which sits infront of my jellyfin instance. So to not use that here I created a seperate router in Traefik for Symfonium and was attempting to configure custom headers as a means of added security to the endpoint. The 404 errors from Traefik are because Symfonium was not using the custom headers I had added. If this is out of character/expectation to you I can turn up logging but in my testing I found that if I added the custom headers as per the process steps I outlined this worked, hence my conclusion.
For clarity, my jellyfin configurations have not changed as a result of connecting Symfonium or configuring the custom headers.
The feature works and is used by many. So as said the custom headers are sent for all requests.
So check your proxy logs to see what it received and what you configured, and be sure to respect the RFC and to save the provider after adding the headers.
No disagreement the feature works but I’m certainly seeing some unexpected behaviour.
I altered my traefik proxy to write out logs in json format and configured it to retain the headers in the log files.
TLDR when attempting to update symfonium’s media provider to add a custom header which has already been enabled on the proxy I get a failure scenario where only 2 out of the 8 connection requests include the custom header, the other 6 requests omit it entirely.
How can I share the mentioned log files below with you?
symfonium.log is off my phone and is in the BST (UTC +1) timezone, the remaining logs are from traefik and in UTC so please adjust accordingly.
01-Clean-Start-NoHeaders (SUCCESS).log - I removed all media providers in symfonium, force stopped the app and restarted it. Traefik was configured to allow connections without any headers. As expected this worked perfectly.
02-AddTraefikHeaders-AddSFNHeaders (FAIL).log - I updated my traefik config to now require new connections to present a custom header called ‘Approved-Source’ with a value of ‘test’. I then attempt to update the existing media provider in Symfonium and this fails with an error with the username or password. This is also where the connection logs from traefik suggest that Symfonium isn’t sending the headers in all instances.
03-NoTraefikHeaders-AddSFNHeaders (SUCCESS).log - I remove the custom headers from the traefik config so it is now again matching scenario 1. However I still have the custom headers configured in Symfonium. This works given I expect traefik is just ignoring the additional headers it is receiving. Is it possible that Symfonium is validating a configuration without the custom headers present and only once this is validated does it commit and use the header config?
04-AddTraefikHeaders (SUCCESS).log - Lastly I reapply the custom header config in traefik. I force restarted Symfonium and it still works.
Note if I now change the custom header value in traefik and do not update the value in Symfonium and attempt a sync it fails and reports the provider as offline. To update Symfonium with the new header value I need to follow the above process to get it to work.
Ok so some of those requests are the current provider still checking server presence so normal.
But yes seems the refresh token call does not send the headers hence the auth error. Will fix in next release.