Last modified: 2008-06-06 06:35:22 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T16330, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14330 - password on automatic created accounts does not work after sul deletion
password on automatic created accounts does not work after sul deletion
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: High major with 10 votes (vote)
: ---
Assigned To: Tim Starling
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-29 13:05 UTC by spacebirdy
Modified: 2008-06-06 06:35 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description spacebirdy 2008-05-29 13:05:23 UTC
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: http://members.chello.at/spacebirdy/ramsch/sul-problem1.jpg

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]]
Comment 1 spacebirdy 2008-05-29 13:15:21 UTC
Please see also
http://meta.wikimedia.org/w/index.php?title=User_talk:Spacebirdy&diff=1016778&oldid=1016758&rcid=1054948

for some users also the e-mail had got lost after the sul deletion.
Comment 2 Brion Vibber 2008-05-29 17:04:46 UTC
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.
Comment 3 spacebirdy 2008-05-29 18:22:38 UTC
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.
Comment 4 Larry Pieniazek 2008-05-29 19:19:02 UTC
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...
Comment 5 Kal 2008-05-29 23:21:00 UTC
@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.
Comment 6 spacebirdy 2008-05-30 17:29:59 UTC
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. http://pastebin.ca/1034223
*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.
Comment 7 Cometstyles 2008-06-03 03:08:03 UTC
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
Comment 8 Titoxd 2008-06-03 04:59:30 UTC
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).
Comment 9 Victor Vasiliev 2008-06-04 20:30:51 UTC
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.
Comment 10 Brion Vibber 2008-06-04 23:07:45 UTC
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.
Comment 11 Tim Starling 2008-06-05 13:01:11 UTC
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.
Comment 12 Tim Starling 2008-06-06 06:35:22 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links