[BUG] Potential Chrome CORS problem with local output

cc @jakirkham @canavandl @martey

Under certain circumstances, loading local HTML Bokeh output can result in the error:

Access to script at ‘https://cdn.bokeh.org/bokeh/release/bokeh-2.0.0.min.js’ from origin ‘null’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

The circumstance is this: BokehJS was previously first loaded from CDN without SRI/crossorigin attributes on the script tag, and then subsequently later, was loaded with them present. Evidently Chrome uses the cached headers and decides there is a mismatch. Steps to repro:

• clear cached images and files in chrome
• open a private window
• navigate to iris example in docs gallery
• run iris.py and open local iris.html file in a browser

When can this happen? For one, CDN loads in autoload_static were not fixed up in the last release, and still use “bare” script tags. So I think anyone who views our garllery first, then output_file output, will run in to this.

• A force-reload will fix and allow things to work (but a bad UX)
• Have not yet tested to see if other browsers are affected (but I don’t think so)

Certainly, we should fix up autoload_static ASAP so that gallery viewing does not instigate this for users. Should be easy and can go in a 2.0.1 next week.

But user generated output could also instigate this for viewers if the users use “bare” script tags in their Flask app or whatever. We don’t really have control over that.

Is there another fix or mitigation we can apply to make sure it always works, regardless? Would adding an crossorigin="anonymous" even to script tags without SRI hashes fix this? (I will try to test out later).

Thoughts welcome.

Some references:

• our AWS Cloudfront/S3 setup is as described here: https://www.boxuk.com/insight/enabling-cross-domain-access-in-cloudfront/

• WONTFIX issue in Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=67743#c17, specifically relevant:

  it is still possible to get the reported error when the response is cached (because the new CORS headers from the server are unknown to the browser when it retrieves the response from the cache). This is an open issue in the specification (https://www.w3.org/Bugs/Public/show_bug.cgi?id=23653). To work-around this problem as a user, just clear the browser’s cache.

[bryevdv]

@hmanuel1 This means at some point your browser has first loaded BokehJS resources from CDN without the SRI hashes specified, then later tried to load them with the hashes specified. I don’t know where or how this happened for you. AFAIK all the docs have now been updated to always specify the hashes, but it’s possible there might be something in the docs (or an example) that was missed and that generated output without the hashes that you then viewed. There’s nothing for anyone to do except for you to force-reload the page (once). [1] Otherwise if you ever happed to notice a page that loads BokehJS >= 2.0.1 without specifying the integrity attribute on the script tag, please point it out to use so we can change it.

[1] Many people think Chrome’s SRI policy wrt cached scripts in this instance is bad/incorrect. Perhaps Chrome will change some day.

[bryevdv]

@UlyssesInvictus @martey Thank you for you comments. The only reliable process that was ever discovered to repro this involved cached files and exactly matched the details of other Chrome issue I linked much earlier. Accordingly, I don’t actually think any AWS-side changes can resolve this, except perhaps not allowing caching at all, and that is too costly for us. In retrospect, this conclusion probably should have occurred to me earlier.

Now, it seems there may be other ways to trigger a CORS problem but there has never been any reliable way to repro them. Which means the cycle time to just “try something and see if there are still user reports” can stretch into months or years (we are already at that point!) out to “forever”.

Given the especially egregious “blank page” failure mode, that is just not acceptable, unfortunately. I think the decision to remove the SRI hashes in output the library generates should stand.