Broken login flow with user subdomains and external proxy on 5.0.0b1

[johnpmayer]

Bug description

Under the following conditions:

• version 5.0.0b1. In particular, after the XSS fix and in particular the change to no longer set domain on the hub's login cookie. (I suspect all 4.1.x versions are similarly affected, though I have not verified. we're on the main branch for reasons)
• have enabled per-user subdomains
• be using an external proxy, in particular an HA one like traefik + redis, which inherently has consistency delays, which the "redirect loop" mechanism is specifically designed to accommodate.

In the event that the route is still not setup, the hub will handle the request:

https://user-subdomain.hubdomain/user/user-name/lab

This is handled by the PrefixRedirectHandler handler class. This route is unauthenticated. It will redirect to:

/hub/user/user-name/lab

which of course, resolves to the full URL on the subdomain:

http://user-subdomain.hubdomain/hub/user/user-name/lab

which is handled by the UserUrlRedirect handler class. This route is authenticated.

Previous Behavior

Previously, as the login cookie had domain set, the browser would still send the login cookie even when interacting with the hub via the subdomain, and so the redirect flow would work fine. Eventually, the redirect loop would cease when the routes reached consistency, and the end-user will settle on their singleuser server.

I've verified this on an older revision on the main branch.

Observed Behavior

Since the change to the domain property of the cookie, the user is now redirected to the login page - on the subdomain in fact - because the login cookie is not sent by the browser to the hub, as the browser is navigating to the hub via the subdomain, so the hub doesn't recognize the session as being logged in. The end-user never lands on their singleuser server.

How to reproduce

Without actually going and manually disabling a route, I found that comparing the behavior of

http://user-subdomain.hubdomain/hub/user/user-name/lab

before and after the change to the domain property of the cookie is sufficient to demonstrate the issue. I imagine this technique would work with e.g. the z2jh CSP with subdomains enabled (though of course in a CSP-based setup, with the single-node proxy and synchronous api, I doubt this issue would manifest)

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[johnpmayer]

I have a low-confidence suggestion to fix: when subdomains are enabled, the PrefixRedirectHandler could (and maybe only for /user) strip the subdomain, or otherwise hard-code the host of the hub domain in the redirect, rather than the current behavior which is to redirect with a relative location /hub/user.

This way,

https://user-subdomain.hubdomain/user/user-name/lab

would redirect to

https://hubdomain/hub/user/user-name/lab

in which case, things should work as expected.

[minrk]

I'll try to do some testing, but I think you're right that it should explicitly redirect to the hub domain when domains are enabled.

[minrk]

#4805 fixes this and adds a test that fails without the fix