Hello,
I am new to all things JH, and am currently accessing JH v4.0.2 via an iframe within an angular application running on the same server. I would like to be able to hit the jupyter/hub/api/user endpoint per each user that is logged in, in order to see if they have a server running via the server element in the response, and then navigate there directly (or to the spawn page). I should note that if the user is not yet logged in to JH, they are automatically sent to the login within the iframe first, and login is managed via IAM.
I have successfully hit the jupyter/hub/api/user endpoint by creating a token in jupyter/hub/token and using that in the request header with the Authorization key and token <my token> as its value. However, I would like this request to be called on behalf of the user that is currently logged in to JH, and not have to hardcode tokens within the app.
I was looking into the JH cookies noted here, but cannot figure out if I am able to use something from within the jupyterhub-hub-login cookie in the api requests, and if so, how? If i should add a package that allows me to check for the presence of a specific session cookie and try to navigate with that information? Or something else completely? I noticed that one to two api tokens are created for me on login/server start but don’t know if I’m able to use or access them.
In the future, I would also like to be able to spin up a server with resource specifications of my choosing.
I don’t think JupyterHub’s cookies are what should be used here. API requests on behalf of users aren’t generally cookie-authenticated.
The standard way to do this would be to register a Service with permission to issue or receive tokens on behalf of the user (a service doesn’t need to be a running process, it can be an occasional maker of API requests from anywhere).
There are two ways to do this:
the service itself has the tokens scope, which is a very high-level scope, essentially allowing it to issue credentials on behalf of every user whenever it wants with arbitrary permissions, without any user interaction, or
the service is a JupyterHub OAuth client, and requests the desired permissions. When OAuth completes, it will receive a token with the requested permissions. This is governed by the service.oauth_client_allowed_scopes field.
The first approach is simpler to manage, but is less secure since one entity has extremely high permissions on behalf of users.
In the second approach, the service does not have any permissions until a user visits it, and then only permissions to manage the users that have visited it.
So my recommendation would be to configure your landing page as a ‘service’ from JupyterHub’s perspective, with the desired permissions. Then it can make the requests you want it to, and you can store the resulting token where/how is appropriate for your application.
You likely noticed the API token issued to the server itself (the ‘server token’, which is accessible in the server environment as $JUPYTERHUB_API_TOKEN), and then the second API token issued upon authenticated access to the server, which is issued as the server’s oauth client, and stored encrypted in a browser cookie.