2024-05-02, 01:59 AM
(2024-04-14, 01:14 AM)TheDreadPirate Wrote: The reason I ask is because in apache and nginx there are optional configs that can break Jellyfin with WebOS, specifically. And I wonder if those options are enabled in whatever reverse proxy this Cosmos stuff is using.
https://jellyfin.org/docs/general/networking/nginx/
Code:# Content Security Policy
# See: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
# Enforces https content and restricts JS/CSS to origin
# External Javascript (such as cast_sender.js for Chromecast) must be whitelisted.
# NOTE: The default CSP headers may cause issues with the webOS app
#add_header Content-Security-Policy "default-src https: data: blob: http://image.tmdb.org; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe- inline' https://www.gstatic.com https://www.youtube.com blob:; worker-src 'self' blob:; connect-src 'self'; object-src 'none'; frame-ancestors 'self'";
I just ran into error code -27 while trying to connect on an LG webOS TV. This looks promising as a solution. Before I start digging into my nginx config, could you clear up some confusion for me?
I can't tell if the commented out CSP header is intended as a solution, or if it is offered as the default. Looking at the network tab in my browser, it doesn't look like I have any CSP at all presently, so that doesn't help me answer my own question.
If the commented out header is the default, where can I find the changes I should make for webOS?
If the commented out header is the fix, I will try it, but I do have a question. Why should we use unsafe-inline? Doing so without strict-dynamic mostly annuls the point of a CSP. For this case, I don't think I'm too worried, this is all for personal use. No one is going to be sending me links to my own site and Jellyfin doesn't look like it has much surface area for these kinds of attacks. So I'm not really that worried about XSS, but using a CSP just to put unsafe-inline still raises a red flag.