[BUG] chromecast for jellyfin is broken by commit 6f715575

[Zazcallabah]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Using the current jellyfin.subdomain.conf template, everything works nice until you try to cast to a chromecast. Then the chromecast gets stuck on "Ready to cast" and nothing happens.

Expected Behavior

No response

Steps To Reproduce

The culprit is the line

add_header Access-Control-Allow-Origin "luna://com.webos.service.config" always;

added here 6f71557

I do not know -why- this breaks chromecast, but removing this line makes chromecast work for me again. I have solved -my- issue, but maybe add a comment to the line in the conf file? or maybe comment that line and ask ppl to uncomment it if they plan to use webos? idk.

[Zazcallabah]

If i were to make a guess, the default jellyfin behavior is to send "access-control-allow-origin: *" but this add_header line replaces that with one specific to webos, effectively nuking all other web-based external clients.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[biscober]

It's still an issue

[Zazcallabah]

Yeah, this behavior where a bot auto-closes "stale" issues is so annoying, because it makes you feel ignored and unseen.

Hey @Noneangel @quietsy please revert #731
it broke a bunch of stuff around cors for anything NOT webos

[Noneangel]

I am sorry that my "fix" broke your config.

I don't understant the line that @quietsy suggested as a change in my MR. Could you try my initial commit (dd15bfc)?

edit: could you test by replacing

add_header Access-Control-Allow-Origin "luna://com.webos.service.config" always;

with

if ($http_user_agent ~ Web0S) {
   add_header Access-Control-Allow-Origin "luna://com.webos.service.config" always;
}

[Zazcallabah]

Ok, just to set some basics: (Sorry if this is redundant or mansplaining.)

I dont know the details on how webos is supposed to work, or the internals of a chromecast, but I do know CORS. (See https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS)

Basically, it allows a webserver to tell a webclient if it should or should not run scripts and download files from the server in question. The client is of course free to ignore these hints, but major browsers follow them, as do chromecast, and probably webos too.

If a server (like nginx) changes the Access-Control-Allow-* headers it responds to clients with, it can majorly affect the functionality of those clients.

Your original commit looked fine. I think. I don't know the details but an X-* http response header will not affect much except for clients specifically listening for them. I assume WebOS does this. The additional if-statement also made sure it only was sent to clients that identified as webos, making the repercussions of the commit very limited.

The later removal of the if-statement, and the change from setting an X-* header to setting the main cors header (Access-Control-Allow-Origin) means the change went from a christmas-cracker to a stick of dynamite, so to speak.

If you respond to requests with Access-Control-Allow-Origin: "luna://com.webos.service.config" you declare that the ONLY scripts allowed to run must be requested from the webos service. Nothing else may run. The only thing letting the main jellyfin web app run is something called "shared origin".

So this commit basically says "anything not webos (hosted from luna://com.webos.service.config) may not run or download files from this webserver" and then it was just committed and merged without further examination. Forgive me if this annoys me.

tl;dr: I havent tested your suggestion, @Noneangel, but from sight-reading it it looks like it will solve the issue.

[Zazcallabah]

The reason I find this issue so important is that using linuxserver.io/swag for reverse proxy is the suggested way to get https and letsencrypt working from the official jellyfin docs. So anyone following those docs will see their installation broken in this way until this is fixed.

[Noneangel]

Sorry if this is redundant or mansplaining

My English skills aren't good enough to detect mansplaining 😄.

To narrow the scope of the impacted clients, those clients work with the current configuration (the one with CORS breaking Chromecast):

• Jellyfin for Android TV
• Jellyfin for kodi - Add-on mode
• Jellyfin Media Player

If you test and validate my suggestion, I can make another MR. Or maybe you can, as if further modification and testing are needed, I will not be able to test: I do not own Chromecast.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.