Shutting down another users server

[dpmatthews]

Sometimes it is useful for users to be able to shutdown a UI server (e.g. to pick up a new version). This is easy to do via the hub for your own server but not for another users server (which you have authorised access to). There are 2 possible ways I can see we could support this:

1. Provide an interface which instructs the UI server to shut itself down.
2. Use the JupyterHub API to shutdown the server by providing a link from the UI dashboard.

Either way, access to this feature should be controlled via authorization (e.g. someone who only has read access should not have access to this) even though this is only psuedo-security (they can still do it they know how to access the API).

[oliver-sanders]

The JupyterHub API already has authorisation, so no psudo security involved, if we were to implement this in the UIS we would want to lean on the existing JupyterHub auth config for this.

[MetRonnie]

The JupyterHub REST API for stopping a user's server: https://jupyterhub.readthedocs.io/en/stable/reference/rest-api.html#operation/delete-user-server

I had a quick go at adding a button for this in the UI but found the DELETE request was not authorised due to XSRF mismatch - the XSRF cookie token at /user/joe.bloggs/cylc/ is different from that at /hub/home/. I didn't get any further than that

[oliver-sanders]

I think https://redirect.github.com/jupyterhub/jupyterhub/issues/4845 explains this xrsf issue and may provide a workaround.

[MetRonnie]

1. Provide an interface which instructs the UI server to shut itself down.

Had a play about with this and came up with something that seems to work (via a POST request to /user/joe.bloggs/cylc/shutdown): 1.8.x...MetRonnie:shutdown-server

[oliver-sanders]

This will work, but conflicts with the Jupyter authorisation which delegates this perm with the delete:servers scope. I think we may be able to hook into that config from the server, else, just push the operation to the hub.

The feature that Dave is requesting is no so much the ability to stop the server, but an authorisation layer (tangental to the Jupyter Hub one) which allows us to control who is able to do so (the psudo security bit).

[MetRonnie]

I think it should be fairly easy to limit the shutdown handler to only work if the user has our CONTROL permissions through modification of the @authorised decorator, if that is what is required?

Unfortunately I don't think we can issue requests to the hub from the server's origin, as it is blocked due to the cross-site checks

... JupyterHub doesn't accept that, since it would permit user-to-user requests on single-domain deployments.

jupyterhub/jupyterhub#4845 (comment))