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
Log out (the user should be logged out in both tabs)
Log in again in the first tab as a first user
Go to the second tab and try to log in using a different account- second user
The user sees, "A user is already logged in. Please refresh the page to continue."
Refresh the page manually
As a result of refreshing the page the user is logged in as the first user, not the second user (the email and password that was typed in in log in fields)
This is the expected behavior at the moment. However, I do think that this sequence can be confusing. Even if you aren't trying to log in as a different user, it is probably confusing to be told to refresh the page in order to log in. @lognaturel wrote:
I do agree it would be more helpful for the second login attempt to log the first user out and then complete.
Note that seeing that message is possible even if there aren't currently two open tabs:
Open two tabs, navigating to login.
Log in in one tab, then close the tab.
Submit the login form in the second tab.
Part of the reason why Frontend is set up this way is that it's not easy to log out from a tab that's not logged in. Frontend doesn't have access to the session token in the cookie, because the cookie is HTTP-only. Frontend only obtains the session token from logging in (from POST /v1/sessions or from GET /v1/sessions/restore). However, the Backend endpoint for logging out (for deleting the session) requires the session token in the URL. So from the perspective of Frontend, right now the only way to log out is to first log in.
Frontend could do something like that, sending a request to GET /v1/sessions/restore in order to obtain the token needed to delete the session. However, the login flow in Frontend is already pretty complicated, and I think it would be a good idea to keep it simpler where possible. I'm thinking that it would be useful to add an endpoint to delete the current session, something like DELETE /v1/sessions/current. Like GET /v1/sessions/restore and GET /v1/users/current, this new endpoint could use the cookie to identify the current session.
Either way, I wanted to make a note about a couple of cases that could come up if we decide to log out after attempting to log in:
If an invalid email address or password is submitted in the second tab, the current session will still be deleted. Any tabs that are logged in will immediately be logged out. Note that right now, a login attempt requires prior logout. Otherwise login will be attempted with cookie auth but without a CSRF token, and Backend will reject even though an email address and password has been provided in the request body.
I think this is another place where we could consider changing the behavior of Backend. If cookie auth is attempted, but there isn't a CSRF token, maybe Backend needn't eagerly reject, but could instead proceed as if no auth was provided. Login would be possible in that case, because POST /v1/sessions doesn't require a session token, but rather an email address and password.
If the same user logs in in the second tab as who logged in in the first, the first tab will still be logged out. That's again because right now, login requires prior logout.
The text was updated successfully, but these errors were encountered:
Related questions came up while adding support for SSO. As I mentioned in that discussion, I think the SSO case is actually easier than the non-SSO case: the user hasn't entered other credentials, so it'd be reasonable just to proceed as the logged in user.
A primitive that could be useful for some potential solutions here is the BroadcastChannel.
With that, we can easily sync state across tabs. For instance, if one tab logs in, it could broadcast its newly acquired session to the other tabs, which can then incorporate the token (and then proceed to do X* to make things consistent).
We could also sync logout easily.
*) where X could be a complete browser page reload, or an in-app reload, or anything necessary to make things consistent - eg when another tab logs in as some other user, we don't want to keep displaying projects in a project listing while showing you're now logged in as some user who cannot actually access those projects. Perhaps a complete app reload is safest.
The QA team asked about the following sequence:
This is the expected behavior at the moment. However, I do think that this sequence can be confusing. Even if you aren't trying to log in as a different user, it is probably confusing to be told to refresh the page in order to log in. @lognaturel wrote:
Note that seeing that message is possible even if there aren't currently two open tabs:
Part of the reason why Frontend is set up this way is that it's not easy to log out from a tab that's not logged in. Frontend doesn't have access to the session token in the cookie, because the cookie is HTTP-only. Frontend only obtains the session token from logging in (from POST /v1/sessions or from GET /v1/sessions/restore). However, the Backend endpoint for logging out (for deleting the session) requires the session token in the URL. So from the perspective of Frontend, right now the only way to log out is to first log in.
Frontend could do something like that, sending a request to GET /v1/sessions/restore in order to obtain the token needed to delete the session. However, the login flow in Frontend is already pretty complicated, and I think it would be a good idea to keep it simpler where possible. I'm thinking that it would be useful to add an endpoint to delete the current session, something like DELETE /v1/sessions/current. Like GET /v1/sessions/restore and GET /v1/users/current, this new endpoint could use the cookie to identify the current session.
Either way, I wanted to make a note about a couple of cases that could come up if we decide to log out after attempting to log in:
The text was updated successfully, but these errors were encountered: