[10:28:06] tgr: Hi, is there any smart way to use the LinkBatch approach within a foreach() loop? I don’t seem to currently think of how to use that in this scenario. [10:45:50] xSavitar: you have to use two loops [10:45:59] :( [10:46:28] loop the results, construct titles via newFromRow (which is free), check conditions, add to LinkBatch if they are met [10:46:39] then load the LinkBatch [10:47:08] then loop the results again and now you can use Title::newFromText and the data will be loaded from cache [10:48:16] Was currently looking at some samples here: https://codesearch.wmflabs.org/search/?q=LinkBatch&i=nope&files=&repos= thanks [10:48:27] 2 loops is really the only way to go, thanks again tgr [11:36:37] tgr: A round of look if chanced? I did something! [20:06:08] Question about user login/logout: I am working on a issue on the iOS app where logging out of a computer browser logged into a wikipedia account, when logged out, logs the iOS app out as well. Turns out logging out of the iOS app or logging back in, affects the state of logged in on the computer browser. [20:06:08] The bug iOS wants fixed is to either not get logged out when a browser wikipedia page is logged out or have it auto log back in, but that would cause the web pages to also log back in, possibly undesireably. [20:06:08] Wondering if the mobile apps can have their own logged in/out independent of browser sessions. [20:20:01] No [20:20:23] Not with how MW is currently configured [20:21:05] sbailey: https://phabricator.wikimedia.org/T37220 [20:21:16] Bug reported Nov 2012 [20:24:13] s/is currently configured/currently handles sessions/ [20:24:58] yeah, its basically a centralauth problem [20:26:07] * bd808 hides before anyone assumes he might know how to fix it [20:26:32] bd808: You're the wrong Bryan to know that ;) [20:27:11] I suppose the answer lies somewhere between the other Bri[ao]ns [20:28:03] If I had to point to someone for CA deep knowledge today I would point towards legoktm [20:28:14] * legoktm hides [20:28:30] the proper response :) [20:29:24] in short, we mostly need an interface that allows users to log out other sessions before we get rid of the log out is log out everywhere functionality [20:29:36] Indeed. [20:30:26] yes. there needs to be a panic button somewhere [20:30:38] There is, you just log out of your current session [20:31:19] let me channel ^demon now: Easy! Just get rid of authed accounts! [20:32:08] * bd808 goes back to documenting the twisted control flow that makes DynamicProxy work for Toolforge [20:42:31] Legoktm, Reedy, bd808, Krinkle thanks for the lively discussion and answers. For now I think the solution will be for the iOS app to retain with ***** the username and password required to log back in, instead of those field being blanked out requiring remembering and retyping both, and also provide more visual indications of logged in/out state as that is less clear on the app than on a web page. Fixing the global [20:42:31] logged in/out status sounds like a project with extra features needed as well. Thanks all :-) [20:43:33] sbailey: "retain" like how? [20:43:39] You mean act as a password manager? [20:44:04] Perhaps a bot password could be used for this, so that it is revokable without requiring the user to change their password to log out a lost device. [20:44:19] The app already has those stored securely (as secure as iOS gets) in the keychain. [20:45:59] I assume if a person has access to the device, they have the device unlocked, but that is a good point about security. By having the username and password ****** a person who has access to the device and the opens the app still cannot actually see the UN/PW and if changed remotely will fail thereafter. [20:46:50] A remote UN/PW clear feature is an intriguing idea. [20:47:54] sbailey: the industry norm more or less is to be able to log out sessions (or revoke app-specific pseudo passwords) [20:48:05] facebook, github, gmail, twitter, google etc. [20:48:47] while unintentional, our instant log out at least has made such feature not yet needed. So introducing device-specific log out, would likely want to be coincided with such a feature. [20:48:58] We do have app-specific passwords, via BotPasswords. [20:49:14] as well as OAuth, but I'm not sure if OAuth works with a general login session. [20:49:20] If it does, that would be the ideal solution. [20:49:22] Krinkle, if mediawiki was able to disambiguate each device and computer/browser into seperate sessions each independently logged in/out this would be trivial. [20:50:02] Krinkle: it does not. you need OAuth2 and some hacks to do desktop/app logins with OAuth [20:50:10] sbailey: I wouldn't cal it trivial, but yes it'll mostly be a UI/design/privacy/security/performance thing, rather than a feature development thing. [20:51:07] Krinkle, agreed, the desired behavior you mention as provided by most other industry sites is desirable, and my proposal, just a work around for now. [20:51:26] yeah, if the app already stores them, that should be trivial from a security perspective. [20:51:39] Seems like mostly an accidental omission in that case if it doesn't already use them on the login screen? [20:52:07] Krinkle, the app does store them, so making the user experience of logging back in better is possible. [20:52:50] cool :) [20:52:57] I will propose this "fix" for now and see how Josh feels about it. [20:53:05] and other iOS team members. [20:53:13] Thanks all [20:53:35] MW CentralAuth is an undermaintained and currently unowned feature in production. Hence the problems around how to move forward. Fell off the organisational radar somehow. [20:54:17] CentralAuth sounds like it could use some love and maybe oversight by the security team... [20:54:28] +1 :) [20:54:40] "Some". [20:54:57] James_F LOL [21:27:40] CentralAuth should be killed with fire and replaced with a standalone auth service [21:27:48] for several reasons [21:28:02] we just don't have many takers for the killing part [21:29:40] do we like wgSharedTables still? [21:29:48] I don't really understand the iOS problem though, since it has the password, just log in again when you detect the session is dead? [21:30:05] as in, do we support them for 3rd party wikis? [21:32:29] tgr: I think Krinkle's question is "would we be OK with moving the Foundation SUL cluster to be a wgSharedDB/wgSharedTables cluster for shared user accounts?". [21:32:48] (Assuming that someone did the work.) [21:34:12] no, that only works for small wikis [21:34:53] doesn't work with DB clusters, for example [21:35:09] I mean, anything can be fixed with enough work [21:35:54] Right. So our advice is "don't do what we do, and don't do what we don't do". [21:36:19] but the biggest problem with MediaWiki auth is actually not CentralAuth related: you want a separate auth stack to minimize attack surface for code execution vulnerabilities [21:37:02] pretty much [21:37:10] that really only needs a separation of password hash checks though, not a fully isolated auth stack [21:37:35] but I agree that CA should be rethought/replaced [21:37:57] which ... was on the roadmap in 2015 but those plans died in a reorg fire [21:38:02] Sounds like an FY20–21 pitch. [21:38:17] there is little point in isolating password hash checks if any RCE exploit can just simulate whatever would hapen after a successful hash check [21:39:08] in the end, you'll need a full auth stack setting its own cookies on an isolated domain [21:40:45] and it will probably have to include OATH and OAuth and some amount of email handling because those all provide password-equivalent access to a user account [21:40:54] so it's a huge project [21:41:09] but it will have to be done at some point [21:41:33] James_F: I could write it up, but honestly I have no confidence that I could convince anyone that it was a priority project [21:41:37] presumably after the first successful RCE exploit, the way things go here [21:42:05] yeah :( that's what it took at $DAYJOB-2 to fix some similar issues [21:42:08] bd808: True. File a placeholder task and hang things that are blocked by it off it?