[12:29:06] guess I should provision a VM to put the wiki on for my dads work... [17:27:53] anomie: if you feel like reviewing some scary-looking API changes, https://gerrit.wikimedia.org/r/#/q/status:open+topic:titleblacklist,n,z should be reviewable now. [20:26:36] Did we decide git or taballs? :P [20:27:31] I think you got votes for both [20:28:06] tarballs will take care of Composer stuff for you [20:28:12] git is well git [20:57:19] dapatrick: I'm running a few minutes late. I'll be on the hangout at about 2:05. [20:57:32] No prob bob. [21:01:06] anomie: trying to grasp how a provider adding an extra field to the main auth form would work [21:01:13] registration reason, specifically [21:01:38] I add an extra Authrequest on account creation, the field shows up, the user fills it and submits [21:02:18] if at that point another provider gives a UI/REDIRECT response, the submitted data is lost [21:02:38] is it the client's responsibility to persist that data somehow? [21:03:25] it looks like AuthManager should stash it in the session [21:04:28] Each call to the beginXAccountCreation() stashes the initial set of AuthenticationRequests in the session, look at AuthManager.php lines 1025 and 1188. Once the provider's beginXAccountCreation() is called, it's up to the provider to persist it if it needs to. [21:06:50] so the provider is supposed with that session data directly? or persist in testForAccountCreation()? [21:07:05] ...supposed to interact with... [21:09:57] The original set of AuthenticationRequests is automatically passed to the provider's beginXAccountCreation(), it doesn't need to do anything to get that. If it needs the data after beginXAccountCreation(), it should store it the session somehow, probably with AuthManager::setAuthenticationData(). [21:13:27] * anomie disappears now [21:13:39] ah, cool, I get it now, thanks [22:05:24] TimStarling: would you be up for reviewing https://gerrit.wikimedia.org/r/#/c/244586/ ? [23:02:33] csteipp: I need to whip up a "reset password" feature for iegreview ASAP. Do you have any qualms/fears about that? I'm thinking a form that you put your email address into and always get a "reset information sent to email" response. On the backend a single use token in the database that allows changing the password for the account that is associated with the token. [23:04:20] The email would be something like "a password reset was requested for your 'name-here' account at APPLICATION-URL. Use this link to reset your password. If you did not request this, don't worry your account will not change and has not been compromised" [23:58:16] bd808: Yeah, that should be fine. Token should be about 128 random bits, either hex or b64 encoded. Ideally, save a hash of the token you send to the user in the database, so a DB compromise doens't let you compromise current reset tokens. [23:59:01] ah good idea [23:59:03] If you ask for secret questions, I'm going to throw something at you the next time you're in the office. [23:59:15] lol [23:59:37] "what was your first programming language?