Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flow authenticated user model to managers in each request #1250

Closed
Zsailer opened this issue Mar 29, 2023 · 0 comments · Fixed by #1251
Closed

Flow authenticated user model to managers in each request #1250

Zsailer opened this issue Mar 29, 2023 · 0 comments · Fixed by #1251

Comments

@Zsailer
Copy link
Member

Zsailer commented Mar 29, 2023

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant