Is this Let's Encrypt CA related?


bokeh was working fine yesterday. then today, damn thing won’t load.


is this related to the Let’s Encrypt CA shitshow along with FB/IG/WA being down?


No that means the page embedding Bokeh content has changed the Content Security Policy in a way makes the browser refuse to load Bokeh’s JS scripts. Any timing re: Let’s Encrypt is purely coincidental. The CSP is specified purely by the response header for the embedding page or in a <meta> tag on the page, so it’s outside anything Bokeh can affect.

We’ve talked about moving all the “CustomJS” Bokeh models to a separate bundle, which I think could obviate the need for unsafe-eval but the page will always need to have script-src permissions to be able to load the BokehJS <script scr="..."> tags.

1 Like

@Bryan - alright. let’s expand on that.

if i’m running Atom-Nightly → [email protected] → jupyterlab → bokeh==2.3.0…

then, if i’m following correctly, the “page embedding Bokeh” would be Atom, is that correct? or would the page in question be Hydrogen within Atom? apologies for what might be a silly question, i just haven’t dug that far into that particular stack.

would it be possible to somehow leverage the bokeh.Resources class in INLINE mode to get around this particular issue as it appears as though the problem has to do with the script imports from the CDN?

then, if i’m following correctly, the “page embedding Bokeh” would be Atom, is that correct?

That seems plausible but I am afraid I have zero direct experience with Atom.

Again, it’s plausible, but I can’t make any concrete suggestions beyond agreeing it might be worth a try. The other avenue could be it Atom exposes some configuration that would let you make the CSP less strict.

Edit: I should clarify, it’s plausible for standalone output. If you are trying to embed a Bokeh server app, then that cannot use INLINE resources.

@Bryan well…shit.

ok. let me see about taking another approach.

this could be nothing more than just a streak of bad luck on my part, but it feels like my custom marker has been getting borked with just about every single update. if i’ve been following the changelogs correctly, it seems like it’s coming down to more or less migrations of old code to a more streamlined and resilient architecture, which just happens to be breaking my beloved custom marker.

here’s my code:

from bokeh.util.compiler import JavaScript
from bokeh.models.glyphs import Marker

class BuySell(Marker):
    __implementation__ = JavaScript("""
import {Marker, MarkerView} from "models/glyphs"

export class MyTriangleView extends MarkerView {
  _render_one(ctx, i, r, line, fill) {
    const h = r * Math.sqrt(3);
    const a = h;

    ctx.moveTo(-r, a);
    ctx.lineTo(r, a);
    ctx.lineTo(0, a - h);

    if (fill.doit) {
      fill.set_vectorize(ctx, i);

    if (line.doit) {
      line.set_vectorize(ctx, i);

export class BuySell extends Marker {
  static __name__ = 'BuySell';
  static init_BuySell() {
    this.prototype.default_view = MyTriangleView;


the need for the custom marker was that the existing (or former, whichever) triangle glyph is anchored in the center, and i needed something that was anchored on one of the tips as more of a triangular pointer:


which you thought was a good idea, providing additional utility to the existing set of markers.

let’s say i would very much like to bring my custom marker in line with 2.4.0 capabilities. what would be the best way to go about that? as appreciative as i am of your continued assistance and input, i wouldn’t be terribly upset if i never had to log into this particular discourse ever again. :wink:

@shr00mie the person who can best answer questions about detailed BokehJS migration issues does not frequent the discourse often, I would suggest making a GitHub development discussion instead, so that that can be cc’d there.

@Bryan what is the handle of this JS migration wizard?

I’ll ping them once you post.

@shroomie all that said, I am not sure I understand the connection between this OP regarding CSP and your custom extension. What makes you think the custom extension is broken, specifically? And what makes that related to the CSP issue?

Edit: also, I wanted to try to run your code above to determine for myself but it is not a complete Minimal Reproducible Example.


I’m just hypothesizing here. if i’m understanding the structure correctly, atom utilizes chrome, so the initial screenshot is the chrome dev console from within atom, not a standalone chrome browser. i’m not exactly sure where in my IDE ecosystem (Atom → Hydrogen → JupyterLab → Bokeh) the breaking change occurred, but if i’m understanding how bokeh functions (barely), i THINK custom markers are generated on load via Bokeh’s JS subsystem, and because these tend to be non-static entities, the generated template for the custom marker requires the rendering browser to pull scripts from bokeh’s CDN, which is, at least as far as i can tell, what’s causing the current issue.

ergo my desire to get away from this JS implementation and find a way to utilize existing capabilities of 2.4.0 which would, ideally, prevent this from occurring in the future, seeing as if i remove the custom marker from my figure, the whole thing renders without issue with my existing IDE environment.

et voila (with circles instead of custom marker)…


are you looking for the rest of the code for the figure and plots?

Just to be clear: the CSP errors above regard loading BokehJS scripts from CDN. These have nothing to do with any custom extensions. BokehJS has to be loaded for any and all Bokeh content, regardless of whether there are any extensions (also which are compiled on the Python side, FYI).

Some things to examine:

  • Does your code work outside of Atom in “plain” HTML output? Then the issue is with Atom’s CSP, not with the extension code.

  • Does the code work with an older Bokeh version but not a newer one? Then maybe there is an issue with the extension.

sure, but then why does it work in Atom when i remove the custom marker, but fails to generate when using the custom marker without changing any other code.

it’s also not unreasonable to wonder if the versioning of either of these two dependencies might be coming into play:


I would suggest moving this to the GH discussion.