Using Z2JH chart, I have a custom authenticator that receives information in the authorize.data that can be used to lookup a user’s authorization for a particular configuration. .
.
Different instances have different authorizations for the same user, so the auth_state should be specific to the instance they are actively using. An external auth lookup application, called by the “authorize” method, supplies a “canAccess” response from to the CustomAuthenticator using the “data” supplied to the authorize method. A user may “lose” access to an instance, so they need to be re-authorized each time they log into an instance.
When I update the default “login” page to allow users to add the information in place of “password”, the authenticator works fine. The user gets all the cookies and is directed to their instance when they go directly to the /hub/user/{username}/{servername} endpoint, but they are required to fill in the “login” page.
The eventual goal is to disable JupyterHub’s UI layer(api-only mode) including the login page and use the controlling application to create notebook instances, then direct the user to that instance. If a user already has an instance running, then they should be given a link to the instance from the controlling application page. The link will not be shown on the controlling application’s page if the user is no longer authorized access to a running instance, but if a user “bookmarks” the instance url, I need to make sure their continued authorization is verified.
One important detail: The actual authorization service that the CustomAuthenticator is interacting with is not an OAuth flow, but a custom application used by a wider set of applications. The request body to this application contains username and a couple of pieces of information about the instance the user wants to access as well as some ssl headers. The response contains a “canAccess” boolean that is used to inform the response from the CustomAuthenticator.authorize() method.
I created a stand-in for the controlling application that posts the required data to the /hub/login when a user selected the instance they would like to interact with. JupyterHub’s response is an error due to missing _xsrf token.
I could just hand the user the instance url, but without the required data for “authorize”, there is no way to validate the user’s continued access.
How should I be handling the user’s “login” to hub to get the missing cookie? Or is this a place where I should get the user an api_token for the target instance and add the “Authorization” header to the link when it is supplied?
Using version 4.2.0 of the community JupyterHub chart.
TIA for any assistance.
Followup on error. Actual log error shows _xsrf argument missing from POST, followed by 403 warning, then the “Setting new xsrf cookie” and another 403 warning.