[00:34:27] the number of patches in my gerrit list with "WIP" in the title is quite incredible [00:35:35] I guess that's a sign that people either want early input from you or that they want to fill your inbox with notices from gerrit [00:35:52] github is down for me. the world is ending. seek the high ground [00:35:54] "in progress" is a bit of a misnomer when you upload a thing and then don't touch it for months [00:36:12] I would have to admit to being guilty of that [00:36:27] I have WIP patch in ops/puppet that hasn't had an edit for 7+ months [00:54:58] o/ [00:55:14] TimStarling, ori: so are we going to do a mass array() -> [] conversion in core once the version is bumped? [00:55:39] no [00:55:47] we are going to have a random mix of the two forever [00:56:11] you heard the man [00:56:21] CR -2 can't remove the last 10% of array() [00:56:34] alright :( [00:57:10] legoktm: I'm not volunteering, but if it can be done safely then let's do it [00:57:38] it took about 5 minutes on my laptop using phpcs [00:59:17] great [01:02:01] legoktm: You get CI working and I'll merge your mass array-syntax-change. ;-) [01:02:04] boo, you can't shadow the array constructor with a function named 'array' [01:02:12] that would have been a fun troll [01:02:19] legoktm: Just… don't make PHPVersionCheck.php or whatever it's called unparsable. [01:31:15] bd808: anomie: deploying Brad's SessionManager patches now [01:34:29] OTOH I guess if I waited so long I should wait until the end of the Phabricator window [01:34:35] in hald an hour, then [01:34:40] *half* [17:40:32] anomie: James_F can't login [17:40:53] csteipp: Details? [17:43:22] anomie: Sorry, chatting with him at his desk. He's uploading a screenshot to phab, so you should have a ticket soon. [18:59:07] tgr, bd808: Patch for T125114 is up, needs review and stuff. [19:02:26] is there a reason not to add the bug number to the commit summary? [19:02:37] some kind of info leak with the IRC bot? [19:04:39] ah, nevermind, I was just looking at the wrong patch [19:25:39] tgr, anomie: looks like needs_token has jumped up again too -- https://grafana.wikimedia.org/dashboard/db/authentication-metrics?panelId=13&fullscreen [19:25:50] not like before however [20:40:37] tgr: good morning. Not sure it is any helpful, but the need_token errors were apparently all from the 'api' entry point [20:43:33] hashar: thanks. That would mostly match with our "badly behaved user agents" hypothesis for most of them [20:55:02] bd808: how do i submit a change for review for scap these days? [20:55:30] Differential [20:56:02] https://phabricator.wikimedia.org/differential/query/Bl4g_4o5nAT8/#R [21:05:24] tried it, but jenkins failed with some phab-related error so maybe i did something wrong -- https://phabricator.wikimedia.org/D112 [21:06:17] the harbormaster stuff is new since the last patch I submitted. Try poking ostriches or thcipriani [21:07:45] Hrm that should work... [21:08:45] Staging repo maybe? [21:08:46] tgr, bd808: So one part of T125133 is https://gerrit.wikimedia.org/r/267134. There's probably other parts though. [21:08:51] when I ran arc diff, I got an error, but it did succeed ultimately [21:08:57] fatal: unable to access 'https://phabricator.wikimedia.org/diffusion/PHSTAGE/harbormaster-staging.git/': The requested URL returned error: 403 [21:08:57] STAGING FAILED Unable to push changes to the staging area. [21:09:04] because i have two-factor auth enabled, i guess [21:09:32] I use https, shouldn't be it. [21:09:51] "Pushable By: All Users" [21:10:21] 403 from the staging repo tho, weird. [21:10:38] anomie: hmmm... [21:10:51] FWIW, I use 2fa via mobile app. Never had the problem with arc diff not pushing to staging. [21:11:06] Yeah same, that's weird. And permissions seem correct.... [21:15:05] anomie: do you have aminute to drop some sessionmanager science on me or are you heads down on your bugs again? [21:15:22] bd808: Give me a few [21:15:23] thcipriani, ori: I think this calls for a mukunda [21:15:46] sure, feel free to ping me if you want me to run something locally to help debug this [21:15:47] tw isn't here :/ [21:16:47] To releng! [21:16:56] Sort of funny how many people are here in a channel that probably should have been redirected to somewhere else 9 months ago [21:18:01] anomie: ObjectCache::getInstance( $wgSessionCacheType )->get( wfMemcKey( 'MWSession', ) ) should return the session data + metadata array, right? [21:18:11] tgr: Correct [21:18:14] not sure "somewhere else" is particularly well defined [21:18:16] even if the user is logged out, as long as the session is persisted [21:18:25] that does not seem to work for me, on any wiki [21:18:36] for an unauthenticated session [21:27:19] bd808, tgr: The rest of the fix for T125133 should be https://gerrit.wikimedia.org/r/267143 and https://gerrit.wikimedia.org/r/267144 [21:29:58] bd808: Ok, my head is no longer down on bugs. [21:31:52] anomie: So here's what I'm seeing for the loginwiki bug. doLoginStart stores central-login-complete-token data into cache, but when doLoginComplete reads it back there's nothing there [21:32:22] The $token value matches on both calls [21:37:51] bd808: Hmm. That bit of code shouldn't have anything to do with SessionManager... [21:39:14] I've got some debug logging sprinkled around locally. I'm going to try on a wiki where login actually works and see if I can spot a difference [21:42:34] bd808: When I try to login on loginwiki, what I'm seeing doesn't look like a problem with central-login-complete-token data. Also, I'm wondering why loginwiki is trying to handshake with itself in the first place... [21:46:42] bd808: What I'm seeing looks more like the login on loginwiki sets the CA session appropriately, then redirects to Special:CentralLogin/start, which stomps all over the session with a pending session, so then when it redirects back to Special:CentralAuth/complete the session isn't valid anymore. [21:47:01] hmmm... possible [21:47:20] session id was the thread I started pulling on too [21:47:31] but I couldn't catch it in the act of changing [21:52:43] anomie: you are correct that central-login-complete-token is fine. My debugging had a bug :/ [21:53:06] but the data from the session is empty it looks like when the complete step is reached [21:53:54] anomie: when I visit Special:Login on, say, meta, a session cookie is set, but the session doesn't seem to be stored in memcache [21:57:10] loginwiki doing the handshake seems normal, it's how it syncs with the central session stored in memcache [21:57:15] bd808: So what I see when trying it, the POST to Special:UserLogin&action=submitlogin sets centralauth_Session=AAA, which is a validly setup CA session. Then Special:CentralLogin/start sets centralauth_Session=BBB, which is a session that has pending_name and pending_token set. Then when Special:CentralLogin/complete is called, it gets centralauth_Session=BBB instead of AAA, and BBB isn't valid for CentralAuthSessionProvider to provide the [21:57:16] session, so SessionManager generates a new empty session that doesn't have a login attempt in progress. This doesn't happen for wikis other than loginwiki because the centralauth_Session=AAA and centralauth_Session=BBB cookies get set on different domains. [21:59:16] bd808: Hmm. Why is it not going into the code path at SpecialCentralLogin.php line 88? [22:01:20] Oh, duh. Because it's checking $session['name'] when it probably means $session['user']. [22:01:39] Which makes me wonder how it ever worked before... [22:03:17] ha! [22:03:25] changing "name" to "user" fixes it [22:04:17] I do end up trapped on the "login successful" screen [22:04:31] som something else is still a bit wonky [22:31:50] bd808: do you think https://gerrit.wikimedia.org/r/#/c/267156/ is safe to merge now? [22:31:53] [6~[6~[6~ [22:32:18] AIUI in the past every login attempt just created a new session because of this bug [22:32:46] which is crappy but still a known working state [22:32:50] It works for me locally and seems to match the other session keys [22:33:10] it fixes most of the login on loginwiki bug for me locally [22:33:30] one bit that remains strange is that the redirect to target gets lost [22:33:39] but I'm not sure if that is new or not [22:34:11] anomie actually figured the problem out, so I should have just let him patch it [22:35:53] well it redirects you to Special:CentralLogin/status [22:36:01] which just shows a success message [22:36:14] there is no attempt to redirect you back [22:37:58] bd808: ... My random guess as to why the old code didn't break in the same way is because the old code would happily use your logged-in $_SESSION even if MediaWiki thought you were logged out. SessionManager doesn't do that, which is very likely a lot more secure. [22:41:59] blerg. I got a cookie set on my dev box that is redirecting me to https [23:00:56] bd808: do you have a minute to talk about hardware budgets for reading? [23:01:05] maybe i should ping adam [23:01:16] yeah i'll do that, you're busy [23:01:25] adam is a better ping :) [23:01:38] * bd808 won't even be a manager next fiscal