nginx configuration in docs is not working

[mobergmann]

Hi,
first of I just wanted to say that I am not an expert in Nginx.

I (re-)installed Nginx in a docker container (the official image) and wanted to make it accessible with my domain (via a subdomain). But when I tried to apply the provided Nginx configuration in the docs it did not work, the server was not reachable. Luckily I had an old and working Nginx configuration lying around and could apply it/ search for the difference. The only difference I could make out, except that I am not using X-Frame-Options and Content-Security-Policy because one of my devices is running WebOS, was me using the rule:

add_header Access-Control-Allow-Origin "*" always;

I propose adding the rule to the documentation in the example code snipped or at least adding a hint, if someone with experience in Nginx can confirm that the provided rule doesn't break anything for other users, or is in some way harmful (again, I am not an expert in Nginx).

[kimboslice99]

I think JF should provide a "basic" config for each server, one focused on purely getting it up and running, as well as perhaps a "full" config, that may include some quirks.... I would be willing to put in some work if the team is accepting of this

[joshuaboniface]

@mobergmann that rule allows cross site requests unconditionally. It shouldn't break anything; in fact, it stops things from breaking in modern browsers. Exactly what sort of errors are you having?

@kimboslice99 ironically we've gone in both directions. Originally most of the lines were commented out for exactly that purpose, but we started finding more and more people wanted the "good defaults". We're willing to at least entertain any suggestions but we want the default config to be as good as possible for running Jellyfin exposed on the Internet.

[kimboslice99]

Understood! I figure a config which is basic but includes non-breaking "good defaults", and a more filled out config which could break some functionality, would be a good way to handle it...

The following headers could be applied without breaking anything, and could go in a "basic" configuration.

Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Xss-Protection: 0
Referrer-Policy: no-referrer
X-Robots-Tag: noindex, nofollow, noarchive

While other headers such as CORS (breaks trailers, see), CSP (issues with PS4 browsers, maybe others), X-Frame-Options (webOS and Dalvik), and Permissions-Policy could cause issues with specific clients or break features, and could go in a more "filled out" configuration, with a note that some issues may arise from using it

I would be willing to cover Apache, Nginx, and IIS, at least. I also think it would be good if the configurations across web servers were consistent

[mobergmann]

I would also prefer to have good defaults instead of a fully customizable config.

[mobergmann]

@joshuaboniface I already have the server running and can't get the errors without turning off the server. I would rather not do that right now. I wanted to reinstall my server soon, then I can see if I can do that.

[nielsvanvelzen]

I would be willing to cover Apache, Nginx, and IIS, at least. I also think it would be good if the configurations across web servers were consistent

At one point I thought about making a config builder. You'd choose the webserver and some other options (like an input for the domain, whether to enable SSL etc.). It would be similar to https://ssl-config.mozilla.org/. Never went ahead with actually creating that but thought it might be good to share the idea.