[01:50:50] Is there something like "Logout of all active sessions" for MediaWiki? [01:55:05] Niharika: There's a task for implementing a function to terminate specific sessions. This is T58212. One comment there states "Logging out already logs you out of all your sessions." though IDK if that's right. [01:55:05] T58212: add ability to terminate certain login sessions - https://phabricator.wikimedia.org/T58212 [01:56:09] Niharika: Resetting all user tokens usually has a good way of doing it [01:56:24] What are you trying to do? [01:57:04] maintenance/InvalidateUserSesssions.php sounds on the ball too [01:59:42] Reedy: Extension LoginNotify can tell you when your account has been logged into from an unfamiliar IP/device but it doesn't let you do anything about it. [01:59:56] I'll look into that, thanks. [02:00:17] Aha. Yeah, in that case it's T58212 like eddiegp mentioned [02:00:17] T58212: add ability to terminate certain login sessions - https://phabricator.wikimedia.org/T58212 [02:00:20] Oh, I was just assuming this is about to log out all sessions of a specific user you're signed in as. Just tested with my phone & pc, indeed just logging out does this. For terminating sessions of all users on a specific wiki Reedys right. [02:01:37] Niharika: If you're wanting to look at implementing it... I'd speak to anomie and/or tgr|away :) [02:02:08] Login, sessions and stuff have been overhauled in the recent history etc [02:02:50] Certainly, at minimum, a "log all sessions out" would be good [02:03:08] But selectively and targetted, if possible would be obviously preferable [02:04:15] SessionManager::singleton()->invalidateSessionsForUser( $user ) looks to be enough to nuke all for one user [02:04:28] Reedy: Seems like just logging the user out works though. [02:04:33] Like eddiegp said. [02:04:49] And then asking them to reset the password should be good. [02:05:09] Hang on, they'd need their email to be registered to do that, right? [02:05:21] Yes and no [02:05:36] MW has functionality to get a user to change their password at login [02:05:50] But if their account is compromised, and someone has their password... They could easily be the one to change the password too [02:06:05] So I'd imagine that change on login workflow wouldn't be a good fit [02:06:28] Right. [02:06:43] But yes, otherwise, they need an email address attached [02:06:46] Possibly authenticated too [02:09:06] Maybe invalidating all sessions other than their current one and then asking them to reset their password is an option. [02:09:22] But the invader could just as easily do that. [02:09:31] Yeah, indeed [02:09:51] I'm not sure MW is setup for differentiating like that, or at least, doesn't expose an interface for only killing one [02:10:14] I guess, this is where other sites send you an email which can kill it [02:10:22] But AFAIK, they also give hte notifications [02:10:41] Yeah. [02:11:01] Maybe you could have a special token that is sent with the email [02:15:24] I suspect core is going to need a few changes to do a "current session" page like other sites do [02:15:36] Which really should be a progression from the login notify stuff [14:03:24] Reedy: Niharika: I think the discussion got stuck on a point that one would need to add a whole new table for logins. Currently there's a user_token column in the user table and that token is used for all logins. If one logs out, this token is invalidated and you're therefore logged out everywhere. To do this for each session you'd need a token on per-session basis instead of one on per-user basis. That'd mean to add a whole new table storing [14:03:24] sessions, and discussion shows some people think that's not worth it. [14:04:18] It kinda feels like one of those "do it now, or do it later" [14:04:27] Wouldn't surprise me if it happened in future [14:04:34] New tables are cheap [14:04:53] Index, PK it right, and it's good for future schema changes [14:05:21] Are they? I thought schema changes take up a lot of resources. But maybe that's not true when you add a whole new table. [14:05:30] New tables are fine [14:05:45] They replicate easy, as they're a quick query to execute [14:06:00] Schema changes are better if we can do an "online schema change" which is dependant on proper PK's [14:07:28] Okay, than I guess it's not about that, though I read that I some comment iirc, but just nobody cares enough to take the work ;) [14:09:53] It's probably that, yeah [14:42:08] Niharika: SessionManager->invalidateSessionsForUser() is the way to invalidate all active sessions. If you want to do a "invalidate all but the current session", see how SpecialChangeCredentials::success() does it. [14:55:34] eddiegp: (also Niharika, Reedy): MediaWiki doesn't change user_token on logout. But CentralAuth does change globaluser.gu_auth_token on logout to log you out everywhere, though, to avoid bugs like T124409. See also T51890#536298. [14:55:35] T124409: Logging out immediately logs you back in - https://phabricator.wikimedia.org/T124409 [14:55:35] T51890: Logging out on a different device logs me out everywhere else - https://phabricator.wikimedia.org/T51890 [15:05:02] Thanks anomie and eddiegp. This is helpful.