Page MenuHomePhabricator

password on automatic created accounts does not work after sul deletion
Closed, ResolvedPublic


Author: spacebirdy

Dear all,

because of some password problem reports by users I tested the following:

*I activated SUL with wikt:is:User:SpaceBirdyTest
*I logged in to 'meta' and 'wikt:de' (automatic account creation)
*I deleted SUL of SpaceBirdyTest

I could log Meta, there it worked, but
I could _not_ log to de.wikt, I got the error, password incorrect:

I went back to is.wikt tried to merge again, only is.wikt was found, I could then merge from Meta too, from de.wikt still not possible to log in.

Many thanks for Your help,
Elisabeth Anderl [[:wikt:is:Notandi:Spacebirdy]]

Version: unspecified
Severity: major



Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 10:09 PM
bzimport set Reference to bz14330.

spacebirdy wrote:

Please see also

for some users also the e-mail had got lost after the sul deletion.

Indeed, currently those new local accounts would not have any password or email data of their own. Once removed from the global account, they'd have nothing.

spacebirdy wrote:

That is strange, why does it sometimes work, sometimes not.
Please can the password and email set to the global ones once it is merged or it will make the renaming
and the deletion of global accounts for many users impossible.

Many thanks.

lar wrote:

I am glad that this was raised to major, it's potentially going to cause a lot of work to recover from, especially since so many people have access to centralauth right now...

kalathalann wrote:

@brion: Are you sure they don't have email data? I managed to get temporary PWs sent to my email from certain projects where my account was created by SUL. Once I got the temp PW, I set a new password, logged in, and merged the account into my global account.

spacebirdy wrote:

I tested this now several times.

I could not reproduce the email problem but the password problem.
It looks to me that the password does not work anymore after unmerging if one was only logged in for a short time and/or logged out while unmerging.

However sending the password worked, but this might be quite frustrating due to spam protection (can't be send for all accounts in a short time)

Something was strange: please see CentralAuth data for test account Foo0056.
*created on fo.wikt.
*global account activated
*logged in into nah.wikt, es.wikt.

-> global account deleted via centralAuth

password problem on es.wikt (I was only logged in for a very short time and logged out before unmerge)
but password could be retrieved via email

-> when I activated sul again on fo.wikt, sul did not see the other two accounts.
*special:MergeAccount said unification complete (although it is not)
*if I log to es.wikt or nah.wikt and go to special:MergeAccount I see only fo.wikt not the other remaining.

Not sure if that is related to this.

Thanks and best regards.

cometstyles wrote:

It will probably be a good idea to give this bug a high priority since the SUL usurpation requests are now starting to have backlogs on both Meta and english wikipedia and their hasn't been any indications of any improvements or changes since Elisabeth made that comment a few days ago :) ..Comets

titoxd.wikimedia wrote:

How about a stopgap measure: Restricting global account creation in the future to users who belong to the 'email-confirmed' group, and copying the globaluser.gu_email field to the respective user.user_email local fields as part of the automatic account creation script? That can give users the ability to get a new password token sent to their email addresses in case local accounts get separated from the global database.

Yes, that doesn't do anything for accounts already created, but I'm not sure how existing password information could be extracted from the database, as the fields are salted. The only option I can think about is prompting for the user's password when an account is going to be created automatically. That way, there's an unsalted password value that can be fed into User::checkPassword() in an existing wiki (to double-check that the user is indeed who we want it to be), and into User::setPassword() in the new wiki as part of the automatic account creation process (to create a locally-salted value for user.user_password).

Fixed in r35880. Also note, that it won't go live immidiately and will be fixed on the next software update. Please, tell users to log into *all* wikis where they have account or they *may* lost them.

Note I reverted r35880 as it looks a little wonky to me; I want Tim to take a peek over it first to make sure it's doing the right thing.

Fixed again in r35923. I don't see the point of setting user_password more often than just at demerge/delete, so I fixed the salting issue and made it possible to transfer password hashes from the globaluser table to user.

Local accounts with blank password hashes, corresponding to global accounts which were deleted with Special:CentralAuth and then recreated, have now had their passwords reset to the password used for recreation. The remainder will probably have to be done on a case-by-case basis.