I can load, interact with, and even edit the content on this page using Safari 14.04 (the latest I think). I don’t run into any errors. But, the minute I fork the page/notebook, I get a notebook filled with this error: “d3 = TypeError: Origin https://[my username].static.observableusercontent.com is not allowed by Access-Control-Allow-Origin.”
I’m running into getting these kinds of errors all over observablehq.com. I started with Chrome (I even turned off all of my extensions) and couldn’t get past it. With Chrome in incognito mode, I get roughly the same behavior as I’m seeing in Safari (notebooks work fine before forking).
What is the recommended “fix” I can make so that my forked notebooks do not run into this error (e.g., so they function like their parent notebook).
Apologies, if this has been answered somewhere. There are a lot of “Cross Origin” discussions on this forum, but none seemed to provide a solution to this particular issue.
@mootari,
Yeah, that’s what the origin reads. I replaced dulani with <my username> to make the statement more generic/understandable to other readers.
I am seeing this on my own forks and on some other notebooks. I ‘thought’ it was related to Chrome extensions but after I forked in both Safari (no extensions) and Chrome’s incognito mode and got the same result, I decided it wasn’t a problem on my end.
I just created a new notebook and pasted in: d3 = require("d3@6", "d3-sankey@0.12") and got the response: d3 = TypeError: Origin https://dulani.static.observableusercontent.com is not allowed by Access-Control-Allow-Origin.
Also, I just published the notebook for the fork I mentioned earlier and the link is here.
Right, but your original post mentioned https://.static.observableusercontent.com. Looks like Discourse interpreted <my username> as an HTML tag and dropped it, because it wasn’t marked up as code.
Are you using a proxy for web access? Could there be something sitting inbetween your network connection that is modifying response headers?
I’d recommend to inspect the network request: Open your browser’s developer tools, then go to the Network tab and look for a request for d3.min.js. Select that request and review the response headers. They should roughly look like this:
@mootari,
Good point about the HTML tag (I hadn’t noticed that it was dropped). I just edited the post to use square brackets instead.
I do normally work behind a corporate proxy, but I tested both on and off the corporate network to make sure that wasn’t an issue (using both Chrome and Safari, but without restarting either one or clearing their chaches).
I’m off the corporate VPN/proxy now and Safari is doing the exact same thing even with new tabs (or with shift-refreshing a page). So… I just tried Firefox (which I haven’t run for weeks). It worked!! So, I guess my browser is somehow caching/remembering something about how the proxy has mangled observablehq’s headers?
I just tried clearing both Safari’s and Chrome’s cache (while off the corporate network) and it is now working for both of them as well!
Thanks for taking the time to walk me through the troubleshooting steps! I didn’t realize that a shift-refresh in the browser was not enough to flush out the effects of the corporate proxy.
Yeah, the DNS cache can be quite resilient. A fairly reliable way to flush it (on macOS) is to go to System Settings > Network, then disable and reenable your network device (remember to apply the changes in each step).
Looks like Discourse interpreted 