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

Log out current session after logging in in different tab #400

Open
matthew-white opened this issue Mar 7, 2023 · 2 comments
Open

Log out current session after logging in in different tab #400

matthew-white opened this issue Mar 7, 2023 · 2 comments
Labels
backend Requires a change to the API server frontend Requires a change to the UI

Comments

@matthew-white
Copy link
Member

The QA team asked about the following sequence:

  • Open 2 tabs
  • Log in as a first user
  • 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.
@matthew-white
Copy link
Member Author

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.

@brontolosone
Copy link

brontolosone commented Sep 19, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend Requires a change to the API server frontend Requires a change to the UI
Projects
None yet
Development

No branches or pull requests

2 participants