[13:28:51] anomie: how does CA invalid password reset work? [13:30:49] is that something that's only supported for local passwords? [13:32:49] tgr: I'm blanking on what "invalid password reset" is referring to. [13:34:33] anomie: when I go to beta I get a warning about my password not meeting admin requirements, and it's handled much like ResetPasswordSecondaryAuthenticationProvider would work in AuthManager [13:35:04] but there seems to be no way to do that in AuthManager, although now that I look at it more closely, I have no idea how it could be done before, either [13:35:18] an invalid passwords seems to just result in login failure [13:35:41] (invalid as in failing $u->checkPasswordValidity) [13:35:49] is that some kind of custom hook? [13:40:25] tgr: Pre-AuthManager, the provider can use the AbortLogin hook to return LoginForm::RESET_PASS, or can use the isValidPassword hook to do it post-login. In AuthManager, it would just communicate with ResetPasswordSecondaryAuthenticationProvider, which we have AbstractPasswordPrimaryAuthenticationProvider to make easy. But in this case it's likely doing it thanks to an entry in $wgPasswordPolicy (which is checked in User::checkPasswordValidity() [13:40:25] for both pre-AuthManager and AuthManager). [13:44:14] tgr: $u->checkPasswordValidity()->isOk() allows login, while !$u->checkPasswordValidity()->isGood() triggers a reset. In other words, it can return an ok-with-warnings Status object to allow login but prompt for reset. [13:45:00] ah, I see [13:45:11] I think that's missing from the CA provider though [13:45:28] the setPasswordResetFlag call, I mean [13:46:25] tgr: Hmm. Yeah, it looks like you're right. [13:53:26] tgr: https://gerrit.wikimedia.org/r/292924 [13:53:40] thanks! [14:58:58] tgr: Thoughts on whether we can fix T136894 by just changing authprovider-resetpass-skip-label and messages like resetpass-validity-soft, or if we need to figure out a way to change the generic continue button's text too? [14:58:59] T136894: Password not strong enough dialog confusing - https://phabricator.wikimedia.org/T136894 [15:01:41] I actually just wrote a patch to change text in the other direction (missed that somehow) [15:02:00] missed that *task* [15:02:11] 'cancel' makes less sense with AuthManager's workflow, IMO [15:02:39] and was wondering if we need the button at all [15:03:21] or just say 'enter a new password, or leave empty to do it later' [15:13:20] If they type in the "password" field and hit enter instead of tab trying to get to "retype", will it submit the form, fail creating the PasswordAuthenticationRequest thanks to an empty retype field, and so skip the reset? [15:26:34] anomie: that's problematic anyway (currently it would just be intepreted as pressing the skip button) [15:27:05] well, currently as in after https://gerrit.wikimedia.org/r/#/c/292934 [15:27:54] on the web it can probably be fixed via AuthChangeFormField adding a HTMLForm validator, I'll look into that [15:28:08] in the API, I'm not sure if it's a problem or not [15:56:28] anomie: adding a right to $wgGrantPermissions that only exists on some wikis should be fine, right? [15:56:32] no new grant group [15:57:15] nvm, easier to add just on those wikis [16:10:04] tgr: Is there any sane way to make sure the form's "default button" is the Continue Login button instead of the Skip button? https://www.w3.org/TR/html5/forms.html#default-button doesn't seem too promising, unless we add a hidden copy of Continue Login at the top of the form or do some really weird CSS. [16:10:30] anomie: can you quickly look at https://gerrit.wikimedia.org/r/#/c/292951/ and make sure it's sane? [16:13:24] tgr: Looks sane. A 'grant-zeroscript' message would want to be added somewhere, but that could be done in zerowiki's MediaWiki namespace if you don't want to bother with WikimediaMessages for one private wiki. [16:13:47] yeah, that's what I thought [18:30:08] Anyone with knowledge of how scap works and a bit about localisation cache - insight on https://gerrit.wikimedia.org/r/#/c/292745/2 would be appreciated. It seems this kind of try/catch should not be needed. Maybe the problem described is limited to beta labs? We don't have this for other extensions, either. [18:32:30] I think it probably was a beta problem mostly. Ryan introduced a new $wmgSomething var and the beta scap pushed the files out in the wrong order [18:39:09] Krinkle: I commented [18:41:06] thanks [18:53:26] anomie: do you think doing this: https://github.com/wikimedia/mediawiki-extensions-ZeroPortal/blob/master/includes/ApiZeroPortal.php#L289 can cause bot passwords to fail or misbehave? [18:55:16] session detection should not happen again on an internal request, right? [18:55:44] tgr: It shouldn't... If you want to show me the script and send me the botpassword info privately, I'll have a look at things and see if I see anything. [21:47:56] anomie: I just run into a weird bu where the user is not connected on loginwiki but is connected elsewhere (that probably happened when I was turning CA on/off a few times); most of CA works normally but logout breaks since the unconnected account is not affected by the central token change [21:48:22] do you think that's worth fixing or is it too far outside normal operating parameters to care? [23:34:30] Interesting. Previously, if a page contained but not closed, it would still apply [23:34:38] whereas as of 1-2 weeks ago, it does not. [23:34:57] This broke various user script pages that suddenly got subjected to PST [23:35:22] e.g. https://commons.wikimedia.org/w/index.php?title=User:Krinkle/common.js&diff=next&oldid=163579497 [23:37:14] Krinkle: https://gerrit.wikimedia.org/r/#/c/268335/ probably?