-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blocking Cross Origin WebSocket Attempt - behind load balancer #46
Comments
What you suggest sounds like the correct behavior. It's not part of the standard, but it's a "de facto standard" |
Gotta be careful when X-Forwarded-Host unconditionally. See rails/rails#29893 for an example of unforeseen security issues. A bunch of other web frameworks have features that list you explicitly set which IPs to trust X-Forwarded-Host headers from - https://expressjs.com/en/guide/behind-proxies.html. This might not be a problem here for CORS, but something to carefully consider regardless |
Definitely not. Any attacker can set headers as they wish, so it's a bad idea to disable security checks based on the fact that some header is present. Explicitly telling Jupyter through the configuration that it is running behind a load balancer, as suggested by @yuvipanda, sounds like the way to go. |
Maybe add logic around this line to use the value from a configured header ( On second thought, it might still be possible to abuse this by hitting the server directly. Tricky thing. |
gracefully shutdown kernels
When running behind a load balancer/proxy, I get this error:
Blocking Cross Origin WebSocket Attempt
because the
Host
header doesn't match theOrigin
header (from here). However, this is supposed to be the case, as the "real" host will be in Forwarded or X-Forwarded-Host.Would it make sense to check if these are set, and if so, to prefer them to the
Host
header when comparing toOrigin
?The text was updated successfully, but these errors were encountered: