Problems with autoloader js & websocket related with proxy protected sites. Apache2 - Bokeh server HTTPS

Hi my name is Adrián.

I was post a topic some few weeks ago waiting for the SSL connection on Bokeh server. Finally, the release of the version 1.4.0 was be usefully to show my Flask python application in a web page with SSL security. But at present I have a problem related with.

The problem is related with people that try to enter to the web and Bokeh don’t load (autoload.js can’t complete the request, image attached).

*I changed css and js to version 1.4.0(not solution).

These people was navigate to my web from “Free Anonymous Surfing or Browse with Privacy Protection”. On the one hand, I thought that Bokeh server/Apache didn’t know what address they have because they hide this information (using Proxy?). For this reason, I think that the request remaining waiting and it can’t send anything. On the other hand, I think it could be related with the Websocket creation of Bokeh. I suspect about this two possible facts but I am not sure about it. Next, I post the server info and command to run Bokeh server:

apache = 2.4.29-1ubuntu4.11
bokeh = 1.4.0
Flask = 1.0.2
python = 3.7

[FLASK APP]

command = “bokeh serve app1.py app2.py --ssl-certfile=fullchain.pem --ssl-keyfile=privkey.pem --allow-websocket-origin=host --port=5006 --address host --use-xheaders &”

@app.route("/graphic")
def graphic():
script_1 = server_document(host + “/app1”)
return render_template(
“graphic.html”, app1=script_1, template=“Flask”
)

I post this to try found someone knows what could be happening. Also, I would like congrats Bokeh team for the new design of the page and this new version 1.4.0 that is great too.

Thank you.
Regards,
Adrián.

As a continue of the explanation I write above. I have used one of these “adress protective” browsers in order to reproduce the error and it return this:

The 404 for the source map is annoying but harmless, and can be safely ignored. We will be removing the source map URL comments in the published bundles on the next release and these will cease.

As for the other, I can’t really speculate with the information on hand. Useful things to do:

  • set `–log-level=debug on running the Bokeh server
  • report back Bokeh server console logs after a failed connection
1 Like

Hi @Bryan.
First of all thank you for your reply and sorry for answer really late. I was so busy this week with work. On one hand, the problem with “…navigate to my web from “Free Anonymous Surfing or Browse with Privacy Protection”…” was solved using the browser Tor (you can configure it for no blocking javascript). The reason of this problem was that some of these “browse with privacy protection” blocks the javascript execution, especially Bokeh. That fact does that Bokeh does not be loaded.

On the other hand, some people using browsers like Chrome, Firefox,… did not see Bokeh. It’s similar like the problem I explained above, but in this case, I suspect that some firewall configuration blocks the request of this “autoload.js” (image below, same case that I expose above).

image

I will try to post the debug log in order to help you to understand whats going on.

Thank your time.

Best regards,
Adrián.

@Adrian I look forward to seeing what you find and helping if I am able. Though I do feel obliged to state clearly that Bokeh is fundamentally a JavaScript tool. So if there are users who have disabled JS execution, or are in an environment where it is blocked, then standard Bokeh content is not going to function for them, and there is nothing that can be done about that.

The only other alternative might be to generate PNG exports, but of course you will lose Bokeh’s interactive capabilities.