-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Make it possible to use relative URLs #5692
Comments
@dhuebner I'd like to to work on this soon, but I don't have an easy set up to test this in "real" situations. Can you commit to testing a PR to confirm that it satisfies your needs? |
@dhuebner I have a branch that can be configured to use relative URLs for the resources. This is fairly straightforward and works great locally. I am not sure about the ws part. The code that generates the ws URLs uses
It's not clear to me that this would need to change, even in the situation you describe? What is the value of the HOST header after passing through nginx? |
@bryevdv Regarding the |
@bryevdv I found this PR build https://travis-ci.org/bokeh/bokeh/jobs/197098047 but I have no idea hot to install from it. |
@dhuebner does nginx not re-rwrite the host header? I guess I expected that it would. I'm not categorically opposed to having a path for the client to compute the ws URL but that change carries more risk and complexity so I want to be certain it is necessary. To test the PR, here are the steps in broad outline, let me know if I can add more specifics
|
I suppose another option is to merge the current PR as-is, as a standalone improvement, and then to cut a dev build. That would probably be easier for you to test with. If you find it's not sufficient we can iterate on it, but ultimately since you seem to have some JS experience it would probably be much more direct / efficient if you can build Bokeh locally and try out some things in the actual environment. |
I don't know why we don't use relative urls... if they always work we don't need an option to enable them, we could get rid of the --host option and simply prohibit any use of request.host. If it's that simple I wonder if there's a reason we didn't do it that way already though? wss url would have to be built on the client as @dhuebner suggested I guess. |
If absolute urls do turn out to be needed, an alternative approach here would be for bokeh to have an insecure mode which trusts request.host and then the user would have to set up the nginx or other reverse proxy to block evil Host headers before Bokeh sees them. I've seen many people who don't really understand what --host does and they may turn on that insecure mode to get things working and leave it on, though. It's a somewhat dangerous festure. Possibly the mode could complain if there's no X-forwarded header indicating a reverse proxy... All above irrelevant if relative urls work and we can start ignoring the Host header. |
@havocp thank you for your comments, I am inclined now to agree, if we can get rid of the need for |
ping @mrocklin @pitrou who may also have valuable input on this matter. If we can get rid of E.g., as far as I know, the initial connection (before the WS upgrade) is also subject to whitelist checking. Is that not really needed? |
I think if we use the Host header we need a whitelist on it, but if we can cleanse the code of request.host (and ideally add automation to notice future mistaken use) then we wouldn't have to validate it. One approach could be to replace the whitelist code with code to delete the header! |
if removing --host btw it might be friendly to accept it and do nothing (maybe with deprecation message) rather than throwing an error. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I'm trying to get bokeh running in a docker/docker-swarm behind a nginx with path to port mapping.
Unfortunately bokeh produces full URL's when creating links which doesn't work in my case.
Starting bokeh with:
bokeh serve untitled.py --host=* --disable-index-redirect
And accessing it over:
https://my.bokeh.server:8443/9335bf292e454cf8ba1181befd4d4a99/p5006/
Produce links like the following:
<link rel="stylesheet" href="http://127.0.0.1:5006/static/css/bokeh.min.css?v=7246afcfffc127faef7c138bce4742e9" type="text/css" />
I've tried setting the explicit
--host
and also tried the--prefix
option, both doesn't fit my requirements. What would work is a possibility to switch using relative URL's. Means instead ofhttp://127.0.0.1:5006/static/
use./static/
or even betterstatic/
. This is the same approach that shiny Apps are using.For the websocket it could be calculated on the client side
So my enhancement is:
Please, make it possible to enable relative URL generation. For example with
--use-relative-urls
See also https://groups.google.com/a/continuum.io/forum/#!topic/bokeh/lIrCvXZE18M
The text was updated successfully, but these errors were encountered: