Access-Control-Allow-Origin' header is missing on

Not sure if this belongs to nbinteract or binderhub…

I published which uses an nbinteract dropdown widget. If I go to or use this runnable link every seems ok appears but the widgets fail to initialise because has been blocked by the cors policy. it seems that an ‘Access-Control-Allow-Origin’ header is missing on

This is the full error log:

quiz.html:1 Access to fetch at ‘’ from origin ‘’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled. Failed to load resource: net::ERR_FAILED

NbInteract.js:126 No kernel, stopping the runIfKernelExists() call. Use the run() method to automatically start a kernel if needed.

DevTools failed to parse SourceMap: chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/sourcemaps/

DevTools failed to parse SourceMap: chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/sourcemaps/

DevTools failed to parse SourceMap: "

nb during the binder build I get

ERROR: nbinteract 0.2.4 has requirement nbformat<5,>=4.4.0, but you'll have nbformat 5.0.4 which is incompatible

I’m a novice and I’m stuck. How can the CORS block issue be resolved?

Thanks for posting! We did some work on this aspect of the system today, so maybe this is a side-effect of that (we fixed something but also broke something else :-/).

@bitnik when I visit, click “Init widgets” and the requests end up being routed to Gesis, then I see the following in my network inspector:

I think we need to get smarter with the config for setting the header as null seems like the wrong value. Not sure why it happens though :-/ Maybe @minrk knows which part of the nginx manual to read.

For my education does it make a difference if we use a “moved” or “moved permanently” redirect?

Yesterday at the end we used this to set Access-Control-Allow-Origin header:

        add_header Access-Control-Allow-Origin $http_origin;
        add_header Vary Origin;

$http_origin is an nginx variable and it holds value of Origin request header.

arbitrary request header field; the last part of a variable name 
is the field name converted to lower case with dashes 
replaced by underscores

In this case Origin request header is null, that’s why Access-Control-Allow-Origin is also null.

I know this is not really an answer, I just wanted to share my knowledge here and hope that it helps.

1 Like

Do you think it’d be better to use * instead of null?

We tried it yesterday for CORS issue on GESIS, but it didn’t work (

okay, that’s back to denied by Cross-Origin Resource Sharing policy: Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.

OK. Could perhaps use an Nginx map: use the client’s origin if given, otherwise * if not provided?

1 Like

good idea :slight_smile: i will read the documentation to learn how to do that

ah, but wouldn’t we get the same error (“Resource Sharing policy: Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.”) in the end? because that request is also redirected from

I posted some more in

I think that would be an invalid client request. In fact I’m pretty sure that if a client doesn’t supply an Origin header there’s no need to return the CORS header at all, i.e. the CORS response is only required if the client asks for it by setting the request header (but with Nginx maps it’s easier to always set the header but vary the value than to conditionally omit a header).

1 Like

Using map definitely sounds like the right thing anyway, but unlikely to be the root of the original question. The CORS work we did on gesis shouldn’t be relevant to @paddy10tellys request, which was made to, which was unaffected by those changes.

My guess is that a request was made to a server that’s no longer running. I say that because we certainly do set the CORS headers on BinderHub and JupyterHub and the notebook server, but don’t on e.g. the nginx server that handles requests to servers that have been culled. Also, the request that is failing is a request for a kernel, which is far from the first request made while talking to Binder, suggesting that some CORS requests succeeded before the one that failed.

Given that, what I think happened:

  1. server was successfully created via CORS requests to binder
  2. server became idle and was culled (or crashed or otherwise went away)
  3. request to stopped server was handled by the “your Binder’s not here anymore” nginx server, which doesn’t set CORS headers, and is thus stopped during the CORS check stage.

This request was bound to fail because the server was gone, but instead of failing with “404, plus this HTML doesn’t look like JSON”, it failed with a CORS check instead.

@minrk indeed, my project worked initially, then stopped working for no good reason some time later.

But, this wasn’t a one-off. Others have failed over the last week. I kept repeating the introductory nbinteract tutorial assuming I was doing something wrong :confused:

Where would the bashful binders go? How would I find them again?

Interesting thread. Thanks for all the responses!

@manics could you check if this is good way to implement that mapping?

Yes, that looks OK to me!

Binders shutdown if they go idle and receive no activity for 10 minutes. It’s my guess that this is what’s happening. Are you seeing shutdowns quicker than that?

No, not quicker than that. It launches OK. I just get the cors blocking thing every time so widgets don’t initialise