Not sure if this belongs to nbinteract or binderhub…
I published quiz which uses an nbinteract dropdown widget. If I go to Binder or use this runnable link Binder every seems ok
quiz appears but the widgets fail to initialise because github.io has been blocked by the cors policy. it seems that an ‘Access-Control-Allow-Origin’ header is missing on mybinder.org…
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 :-/).
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?
$http_origin is an nginx variable and it holds value of Origin request header.
$http_name
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.
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 mybinder.org
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).
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 hub.gke.mybinder.org, 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:
server was successfully created via CORS requests to binder
server became idle and was culled (or crashed or otherwise went away)
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
Where would the bashful binders go? How would I find them again?
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?
i will read the documentation to learn how to do that