This can be tough to reproduce because session cookies might be sitting around, as might global cookies and.... it gets scary. ;)

But fundamental problem is that there's only a single user_token value, which holds the magic saved cookie that verifies you and restarts your session after the session cookies are gone.

To stay logged in reliably on multiple devices, we need to be able to store multiple remembered-login tokens.

You should get the same token in both sessions, but I'll check that scenario. I wouldn't be surprised if we try to regenerate at some point when you have the remember me checked.

I need to rework some of the token handling in general, so I'll probably look into this after OAuth is out. If this is a serious issue, please adjust the priority and we'll shift things around.

I'd say this is pretty high priority for the mobile team. Logging in on mobile is a pain and a lot of our workflows are optimised to be as simple as possible once logged in and all editing on mobile requires authentication in the current state. Any help here would be greatly appreciated.

OK I can replicate this now:

Login on mobile
Login on desktop
Logout on desktop
Now you are also logged out on mobile

Vice versa
Login on mobile
Login on desktop
Logout on mobile
You are now logged out on desktop.

Yes. Logging *out* refreshes a token, so other logged in sessions will be invalidated. This was done by Tim in 2008, and as I understand it, it's by design.

I personally like that it works this way, in case a user forgets they logged in somewhere and left the browser open. however we could do something like facebook, and provide a button in the user's preferences to log out any other sessions.

Tim, is this something we want to reconsider?

Personally I spend a lot of time over many devices. A lot of the time I might log into my account temporarily on a friends machine and logout. Being logged out on mobile and having to log in again is a pain and breaks my mobile workflow and I'm sure the workflows of others.

Jared - this doesn't seem to be a good user experience. The situation where a user forgets they logged in somewhere doesn't quite hold much weight for me - in this age we have incognito windows, we have a box that says 'keep me logged in' on the login form (I'd assume this would logout that session on closing my browser window) and all sorts of other ways to protect us from this. It seems we could still support this but as more of a power user feature - either as part of the logout process or a user preference.

Thoughts?

I strongly concur with Jon on this one; users (or at least I!) expect to be able to remain logged in on multiple devices, and our current user experience is Broken with a big ol' B.

As far as I know, CentralAuth just inherited the same single-token design from MediaWiki's local auth; I don't think it was a deliberate design decision.

I do think this opens a can of worm for needing an interface for remote logging out of other devices which i really don't want to tackle right now. I've seen both patterns work well (A. log out one place logs you out globally, vs. B.log out on one device only logs you out on that device) One feels more secure (A) where as (B) feels more casual but convenient. From a UX perspective I don't actually have a point of view on this as long as we're being consistent.

If we want to wait until we have a UI for logging out of all or logging out of specific devices available to users I'd be fine with a log out once logs you out everywhere behavior until we can get the multiple login behavior to where we want it.

I thought I was the only one having this annoying problem...

I don't keep a mobile login session for more than one day, even if I don't touch my laptop at all (I realized this weekend, when I had only my mobile device, no laptop).

Hi Quim, if you didn't use another browser where you actually clicked logout, then you're hitting another issue.

Has anyone on the mobile team verified how long a cookie, set for the session duration, actually lasts on a mobile device? I know both bugzilla and gerrit seem to also timeout pretty quickly on my phone, whereas they last almost forever on desktop.

Opened bug 51377 for the other issue. Let's discuss it there.

I am regularly being logged out when using two different browsers (Firefox and Chrome) on the same workstation. I log out of one browser, and I am automatically logged out of the other one. Is this bug the cause? (should the summary be 'log out is always global') MediaWiki:Logouttext should mention that the logout is now global. Is it a regression or planned feature?

(In reply to comment #12)

I am regularly being logged out when using two different browsers (Firefox
and
Chrome) on the same workstation. I log out of one browser, and I am
automatically logged out of the other one. Is this bug the cause? (should
the
summary be 'log out is always global') MediaWiki:Logouttext should mention
that the logout is now global. Is it a regression or planned feature?

jayvdb: Is the situation still as described?

(In reply to comment #13)

(In reply to comment #12)

I am regularly being logged out when using two different browsers (Firefox
and
Chrome) on the same workstation. I log out of one browser, and I am
automatically logged out of the other one. Is this bug the cause? (should
the
summary be 'log out is always global') MediaWiki:Logouttext should mention
that the logout is now global. Is it a regression or planned feature?

jayvdb: Is the situation still as described?

Yes, logout is global

The browsertests are most probably impacted. They are run concurrently in virtual instances and wiki that have shared auth. Whenever a test ends up login out the user, the other tests running in different instances are being logged out.

I am highly suspecting this bug report to be the cause of our mysterious logout and started a thread on QA mailing list about it:

[QA] browser tests race condition with login/logout
http://lists.wikimedia.org/pipermail/qa/2014-July/001643.html

Some site let you login from different devices and list the valid sessions in your user preference. Ie session vary by browser or IP (can't remember details). You can then manually invalidate a session.

I think Phabricator is using that system.

(In reply to Chris Steipp from comment #5)

Yes. Logging *out* refreshes a token, so other logged in sessions will be
invalidated. This was done by Tim in 2008, and as I understand it, it's by
design.

Done by Tim in the CentralAuth extension? Cross-referencing a commit or SVN revision would be helpful for me.

The current behavior (log out anywhere logs out everywhere) has probably become the expected behavior. I've personally relied on the behavior to stop adminbots running under my account, as I recall.

I would like to think that most users typically stay logged in on their devices or use incognito mode on a public computer, but perhaps this is an overly optimistic view.

I personally like that it works this way, in case a user forgets they logged
in somewhere and left the browser open. however we could do something like
facebook, and provide a button in the user's preferences to log out any
other sessions.

[[mw:Extension:SecureSessions]], of course.

User experience versus security again...

Well, I suppose you could simply store it as yet another user preference, so people who prefer user experience have their way and people who prefer security (log out of all browser sessions) also have their way.

Before CentralAuth, logout was local, and password change was an effective global logout, invalidating all sessions and persistent cookies. I remember reimplementing this policy in r5523, I had no problem with it.

The change in policy for CentralAuth was apparently done by Andrew Garrett in r33061. The doc comment on resetAuthToken() indicates that it was a deliberate policy -- although the fact that it is a different policy from the core was not noted. I reviewed it at the time (as evidenced by r33063), but I don't think I considered the logout policy beyond accepting the emphatic rationale in the doc comment.

I am fine with the idea of making logout local again, but I think a nice additional feature would be to add a button to the logout success page which allows you to explicitly log out from all devices, without having to reset your password.

(In reply to Tim Starling from comment #18)

I am fine with the idea of making logout local again, but I think a nice
additional feature would be to add a button to the logout success page which
allows you to explicitly log out from all devices, without having to reset
your password.

Yes, a "log me out everywhere" button sounds like a good idea.

Assuming the logout behavior is changed here at all, a more minimal approach would be to only inform the user in a post-logout message if additional sessions remain open/active.

In my opinion, given that this is a proposed change in perhaps expected behavior (i.e., I imagine some users now expect "log out" to log them out everywhere), user notification in a post-logout message is a hard requirement, while adding an additional tool to actively kill sessions would be a soft requirement.

I would love to see this fixed someday. Maybe a future developer wishlist..

I note it's not as simple as just making CentralAuth not invalidate all sessions, since if you only log out locally (but not on loginwiki) then you're liable to be automatically logged back in (e.g. T124409). You'd have to figure out some method to be able to implement "log out this device's session on all wikis, but not different devices' sessions for this user", which probably means that different devices have to get different centralauth_Token cookies (but still the same cookie for that device on all wikis) and have the different devices' cookies be individually invalidatable.

We could just change logout to delete the cookie but not change the token in the DB, which IIRC is how core works. Although it's somewhat unsafe and it'd probably be better to change core in the opposite direction (have a separate user_sessions table - I believe LoginNotify does that anyway so maybe some of that could be pulled into core).
In any case, I think this is more of a user wish than a developer wish.

In T51890#3445607, @Tgr wrote:

We could just change logout to delete the cookie but not change the token in the DB, which IIRC is how core works.

That's exactly what I was saying isn't so simple. Unless you're going to be redirecting logout through loginwiki and so on, you'll repeat T124409.

and it'd probably be better to change core in the opposite direction (have a separate user_sessions table - I believe LoginNotify does that anyway so maybe some of that could be pulled into core).

CentralAuth would probably need a central user_sessions table, much like it has its own globalusers table, rather than reusing one that might be added to core.

Also, it wouldn't actually log you out from non-edge wikis like outreachwiki... so I guess storing multiple tokens is the only way to do it.

I think T37220 is a duplicate of this?

Agreed.