Detect Hub vs Binder in launch button

[agoose77]

We can programmatically detect the presence of a Hub vs Binder from querying the 1:1 API endpoints in the given URL.

[agoose77]

The canonical relative URLs that indicate a Hub vs Binder are:

• GET hub/api/
• GET versions

Iff. a Hub and BinderHub deployment share the same handler namespace, we should treat the result as a BinderHub.

[agoose77]

This necessitates jupyterhub/jupyterhub#4966

[stevejpurves]

@agoose77 yes that * allow origins change/assumption is a bit of an antipattern? it'll be down to individual hubs to allow the consumers they want to let in and there is already a config surface in jhub for that (as @manics points out).

The way around that for non static sites is to expose a new route that can take the request server-side, but that doesn't help at all for static deployments.

There are no other get requests at all that allow a binderhub to be differentiated from a jupyterhub? mind you isn't having the explicit type set in project.services.xxxx a better/acceptable route forward anyways?

[agoose77]

@stevejpurves I don't think it's an anti-pattern: the reason that this header was designed is to make cross-origin requests possible. In this case, I think we should support cross-origin requests.

For static sites we can also just use a CORS proxy, but these are not great for a variety of reasons.

There are no other get requests at all that allow a binderhub to be differentiated from a jupyterhub?

Not in the default config. That said, I'm not sure how Thebe is able to get around that, but I haven't looked too carefully -- probably a per-hub opt-in?

[stevejpurves]

I don't think it's an anti-pattern: the reason that this header was designed is to make cross-origin requests possible. In this case, I think we should support cross-origin requests.

let me re-phase that - I don't think jupyterhub adding * for it's allow origin header by default is good practice - should be per-hub

[agoose77]

@stevejpurves My proposal is to add it to the unauthenticated routes like /hub/api/ etc., not the top-level!

[manics]

I don't think we should override admin's preferences for which external sites can interact with their hub, even for unauthenticated endpoints.

[agoose77]

@manics how strict are your feelings on this? For example, is GET ${HUB_URL}/hub/api/ something that you wouldn't be comfortable exposing by default?

Furthermore, I want to clarify my intentions -- we should not be overriding preferences, only setting new defaults; If admins want to turn this of, they certainly should be able to.

[agoose77]

@stevejpurves

it'll be down to individual hubs to allow the consumers they want to let in

The issue with the current approach is that in-practice it means that most hubs don't support even the simplest interrogation of "what are you?". It's hard to author a useful feature if by-default it is broken out of the box.

mind you isn't having the explicit type set in project.services.xxxx a better/acceptable route forward anyways?

This is about bring-your-own-hub, whereby we don't know what the service is until the user provides it.