-
Notifications
You must be signed in to change notification settings - Fork 15
Description
As indicated by my janky login form in main...login-test, there isn't much for us to do for login itself besides make a POST to the login endpoint and let the response set the session cookie. The more involved part is how we get to the form and where we go after we're logged in.
We need to think about:
- How/when do we find out we're unauthenticated and need to redirect to auth?
- How do we log in — JSON post from a console page or a form served by Nexus?
- After login, how do we get back to the target page? (Return to target page after login #359)
Right now, we load the bundle no matter what, and can only find out whether we're authenticated when we try to make an API request. This is a pretty bad experience: when the user is not logged in, we first render something that looks like the console, only to send them to a login page after getting a 401 from the API. We could get around this by either:
- 👎 Waiting for an initial
/session/merequest to come back before showing anything - 👍 Serve the console from Nexus, do an auth check on the initial request and redirect to login before even sending down the Console bundle. The login form could be served directly from Nexus (or a third-party IdP). Because we're already assuming we're serving the console bundle from Nexus, we could build the login form as its own page in the Console repo and put it in Nexus's static assets dir however we do the console bundle.
In local dev and on GCP, we're serving the API and console from the same domain, putting the API behind the /api prefix, so all I had to do to make the cookie work was set Path=/api on the cookie server-sid. We may or may not being doing something like that in production, but we don't have to worry about it now.