You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we move in the direction of more multi-tenant Jupyter servers, it's becoming more clear that we need a way to access the current user (and possibly other request context info) from within the managers that sit beneath each service.
As an example, the particular use-case I have in mind is using a custom contents manager with a remote contents provider. Jupyter Server acts as a gateway server to the remote contents service. Jupyter Server authenticates the user, but the remote service also needs to authenticate the user; the cleanest way to do this would be for the contents manager to pass the e.g. authenticated user, token, etc. to the remote service as part of its request.
Today, we don't have a clear, documented way to get the current user from within a manager.
My first thought was to add an extra, optional keyword argument, e.g. context={...} to all public methods in the contents manager base class, but this changes the method signatures in a backwards incompatible way—breaking all custom contents managers.
In last week's Jupyter Server meeting, we discussed that contextvars might be a way to go. Each request creates its own contextvars and this manager could call out to this context for the request handler object (which includes the current_user). We should dive into the option to see if its viable.
If contextvars isn't viable, we'll need to think about the longer term moves needed to flow the request context into the managers. If anyone has ideas, please share!
The text was updated successfully, but these errors were encountered:
As we move in the direction of more multi-tenant Jupyter servers, it's becoming more clear that we need a way to access the current user (and possibly other request context info) from within the managers that sit beneath each service.
As an example, the particular use-case I have in mind is using a custom contents manager with a remote contents provider. Jupyter Server acts as a gateway server to the remote contents service. Jupyter Server authenticates the user, but the remote service also needs to authenticate the user; the cleanest way to do this would be for the contents manager to pass the e.g. authenticated user, token, etc. to the remote service as part of its request.
Today, we don't have a clear, documented way to get the current user from within a manager.
My first thought was to add an extra, optional keyword argument, e.g.
context={...}
to all public methods in the contents manager base class, but this changes the method signatures in a backwards incompatible way—breaking all custom contents managers.In last week's Jupyter Server meeting, we discussed that contextvars might be a way to go. Each request creates its own contextvars and this manager could call out to this context for the request handler object (which includes the
current_user
). We should dive into the option to see if its viable.If
contextvars
isn't viable, we'll need to think about the longer term moves needed to flow the request context into the managers. If anyone has ideas, please share!The text was updated successfully, but these errors were encountered: