Last modified: 2014-09-25 05:26:47 UTC
Appearently somehow an "unattached" account was created with my username (bawolff) on tawiki ( http://toolserver.org/~vvv/sulutil.php?user=Bawolff , http://ta.wikipedia.org/wiki/Special:ListUsers/bawolff?uselang=en&limit=1 ) My understanding is that CentralAuth should prevent this from happening once an account is unified. The account appears to be someone totally different from me (my password doesn't work with it), it was created last month, which is several years after I unified my account. The account does not appear in the new user log ( http://ta.wikipedia.org/w/index.php?title=%E0%AE%9A%E0%AE%BF%E0%AE%B1%E0%AE%AA%E0%AF%8D%E0%AE%AA%E0%AF%81%3ALog&type=&user=Bawolff&page=&year=&month=-1&uselang=en ) Expected behaviour: CentralAuth prevents other people from registering accounts that conflict with a unified account name.
Just tried to register a new account on wikinews using my Unified/SUL "Reedy (test)" account, using a different password, and a different email address I get the error message "Login error Cannot create account: the requested username is already taken in the unified login system." Seems this is RESOLVED WORKSFORME
Can you manually attach it?
Can who? Bawolff? He can't attach it as he doesn't know the password
Similar problem here. https://toolserver.org/~pathoschild/stalktoy/?target=Krenair This lists two wikis where my account is not unified (cswiki and enwikiquote). Login details work for logging into MediaWiki.org, but not those two wikis. (Incorrect password). Go to those sites and you'll see the accounts were created automatically (and, if I understand correctly, therefore should be unified): http://en.wikiquote.org/wiki/Special:Log/Krenair http://cs.wikipedia.org/wiki/Special:Log/Krenair Special:MergeAccount on my home wiki (enwiki) says "Login unification complete!", but does not list cswiki or enwikiquote, and stalktoy continues to say that the accounts on those two wikis are not unified. It's no big deal as I don't intend to contribute on those wikis, but it still seems to be worthy of mentioning here.
Might be a different bug because https://ta.wikipedia.org/wiki/Special:Log/Bawolff?uselang=en doesn't show anything, nor does https://ta.wikipedia.org/w/index.php?title=சிறப்பு%3ALog&uselang=en&page=User%3ABawolff so it's not clear whether that account was automatically created as well. In both cases, [[Special:CentralAuth]] doesn't show the unattached accounts at all. (In reply to comment #4) > Special:MergeAccount on my home wiki (enwiki) says "Login unification > complete!", but does not list cswiki or enwikiquote, and stalktoy continues to > say that the accounts on those two wikis are not unified. To clarify, the user didn't try to unify the accounts via email or password because he wasn't provided with this option. Password reminder fails with: «There is no e-mail address recorded for user "Krenair"».
If the centralauth db wasn't available (timeout conencting, transaction rollbacked...) when creating the account, maybe it gets added to the local wiki but not to centralauth.
I have had the same problem 7 times by now (in words "seven")! Four times I was able to reset my password and unify manually: * zh-yue.wikipedia.org 00:41, 13. Dez. 2008 * ru.wikibooks.org 18:44, 13. Feb. 2012 * ta.wikiquote.org 13:25, 19. Feb. 2012 * kk.wikibooks.org 13:30, 19. Feb. 2012 Three times I couldn't reset my password due to missing email address: * uz.wikiquote.org 20:56, 13. Feb. 2012 * ru.wikiversity.org 10:38, 25. Feb. 2012 * kk.wiktionary.org 10:34, 25. Feb. 2012 Hashar has set the empty email address so I was able to unify manually as usual, funnily the given dates are not the time of creation but time of unifying (see https://bugzilla.wikimedia.org/show_bug.cgi?id=34705). So one in sixty SUL account creations went wrong, IMHO that's a bit high!
*** Bug 17618 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Similar problem here. > https://toolserver.org/~pathoschild/stalktoy/?target=Krenair > This lists two wikis where my account is not unified (cswiki and enwikiquote). > > Login details work for logging into MediaWiki.org, but not those two wikis. > (Incorrect password). > > Go to those sites and you'll see the accounts were created automatically (and, > if I understand correctly, therefore should be unified): > http://en.wikiquote.org/wiki/Special:Log/Krenair > http://cs.wikipedia.org/wiki/Special:Log/Krenair > > Special:MergeAccount on my home wiki (enwiki) says "Login unification > complete!", but does not list cswiki or enwikiquote, and stalktoy continues to > say that the accounts on those two wikis are not unified. > > It's no big deal as I don't intend to contribute on those wikis, but it still > seems to be worthy of mentioning here. The same happens to https://toolserver.org/~pathoschild/stalktoy/?target=Doc.mari
(In reply to comment #4) > Similar problem here. > https://toolserver.org/~pathoschild/stalktoy/?target=Krenair > This lists two wikis where my account is not unified (cswiki and enwikiquote). > > Login details work for logging into MediaWiki.org, but not those two wikis. > (Incorrect password). > > Go to those sites and you'll see the accounts were created automatically (and, > if I understand correctly, therefore should be unified): > http://en.wikiquote.org/wiki/Special:Log/Krenair > http://cs.wikipedia.org/wiki/Special:Log/Krenair > > Special:MergeAccount on my home wiki (enwiki) says "Login unification > complete!", but does not list cswiki or enwikiquote, and stalktoy continues to > say that the accounts on those two wikis are not unified. > > It's no big deal as I don't intend to contribute on those wikis, but it still > seems to be worthy of mentioning here. After seeking a user rename at [[q:Wikiquote:Changing username]], this is now fixed on enwikiquote.
My account is now fully fixed after getting a rename on cswiki. Another user (Bazonka) has also had this bug: [[mw:Project:Requests#Problem with unified login]].
And again someone who has this bug (AArizaga): https://meta.wikimedia.org/w/index.php?title=Steward_requests/SUL_requests&oldid=3598379#AArizaga - according to the SUL it's certainly him/her: http://toolserver.org/~quentinv57/sulinfo/AArizaga. Bumping up priority.
(In reply to comment #12) > And again someone who has this bug (AArizaga): > https://meta.wikimedia.org/w/index.php?title=Steward_requests/SUL_requests&oldid=3598379#AArizaga Workaround done by commons crat EugeneZelenko (renamed the defunct account to [[:commons:User:AArizaga (usurped)]] and moved the temp account). Still this can't be a solution forever ...
Chris, when you're done with your current work, could you take a stab at reproducing this problem? Sam should be able to help you get bootstrapped.
This was bug was originally blocking 1.18wmf1 deployment but has been re-opened in the mean time. Milestoning for 1.20 now in the extension itself. Not blocking deployment.
See also bug 39060.
Elfix and MarcoAurelio are also having trouble - see bug 39996.
I created my account on 26th June 2011 at dewiki and 15(!) projects are "unattached". https://toolserver.org/~quentinv57/sulinfo/McZusatz
Can you confirm that McZusatz cannot login to one of the "unattached" wikis, like yiwiki? The production centralauth database shows McZusatz attached on the wikis that sulinfo shows unattached. Maybe there's a lag in the toolserver replication? mysql:wikiadmin@db37 [centralauth]> select * from localuser where lu_name = 'McZusatz' and lu_wiki IN ('be_x_oldwiki', 'bswiki', 'ckbwiki', 'kowikiquote', 'kywiki', 'mrjwiki', 'newiki', 'pawiki', 'plwikinews', 'rwwiki', 'shwiki', 'skwiki', 'wikidatawiki', 'yiwiki', 'yiwiktionary'); +--------------+----------+-----------------------+--------------------+ | lu_wiki | lu_name | lu_attached_timestamp | lu_attached_method | +--------------+----------+-----------------------+--------------------+ | be_x_oldwiki | McZusatz | 20121122201030 | login | | bswiki | McZusatz | 20121124214652 | login | | ckbwiki | McZusatz | 20121124214619 | login | | kowikiquote | McZusatz | 20121126160606 | login | | kywiki | McZusatz | 20121122131322 | login | | mrjwiki | McZusatz | 20121127212428 | login | | newiki | McZusatz | 20121127220205 | login | | pawiki | McZusatz | 20121126095351 | login | | plwikinews | McZusatz | 20121127220205 | login | | rwwiki | McZusatz | 20121127212428 | login | | shwiki | McZusatz | 20121127220205 | login | | skwiki | McZusatz | 20121120202130 | login | | wikidatawiki | McZusatz | 20121121222245 | login | | yiwiki | McZusatz | 20121120224558 | login | | yiwiktionary | McZusatz | 20121120224612 | login | +--------------+----------+-----------------------+--------------------+ 15 rows in set (0.00 sec)
(In reply to comment #19) > Can you confirm that McZusatz cannot login to one of the "unattached" wikis, > like yiwiki? > mrj.wiki: I could not log in every time I tried before (wrong password; could also not reset the password, because the mail was unattached; But user seemed to be existet on the wiki) > The production centralauth database shows McZusatz attached on the wikis that > sulinfo shows unattached. Maybe there's a lag in the toolserver replication? > Now it works magically. Could be because the account was just created (20121127212428) ?!?
We haven't had reports of this in a while, and hopefully the SUL finalization will make this moot.
(In reply to comment #21) > We haven't had reports of this in a while, Have you run a query to see if there war more instances? Or are you relying on the fact that the 52nd duplicate was not reported yet? :) > and hopefully the SUL finalization > will make this moot. Why? Surely my unattached accounts have not been attached as of now.
(In reply to comment #21) > We haven't had reports of this in a while, and hopefully the SUL finalization > will make this moot. New report: Natuur12 experienced the same on the French Wikipedia. It was automatically created in February 2013 (see https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Journal/Natuur12) but he was never be able to login or to reset the password. He got this error in French: « Erreur lors de la création du compte. Le compte utilisateur n'a pas été créé, car nous n'avons pas pu identifier son origine. Vérifiez que vous avez activé les cookies, rechargez la page et réessayez. » * https://fr.wikipedia.org/wiki/Discussion_utilisateur:Vlaam#gebruiker:natuur12 * https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/19_septembre_2013#Difficult.C3.A9_.C3.A0_cr.C3.A9er_un_compte I'll ask a French bureaucrat to rename his account and to give him the chance to get a new account again.
(In reply to Bawolff (Brian Wolff) from comment #0) > Appearently somehow an "unattached" account was created with my username > (bawolff) on tawiki ( http://toolserver.org/~vvv/sulutil.php?user=Bawolff , > http://ta.wikipedia.org/wiki/Special:ListUsers/bawolff?uselang=en&limit=1 ) > My understanding is that CentralAuth should prevent this from happening once > an account is unified. > > The account appears to be someone totally different from me (my password > doesn't work with it), it was created last month, which is several years > after I unified my account. The account does not appear in the new user log > ( > http://ta.wikipedia.org/w/index. > php?title=%E0%AE%9A%E0%AE%BF%E0%AE%B1%E0%AE%AA%E0%AF%8D%E0%AE%AA%E0%AF%81%3AL > og&type=&user=Bawolff&page=&year=&month=-1&uselang=en ) > > Expected behaviour: CentralAuth prevents other people from registering > accounts that conflict with a unified account name.
(In reply to Nemo from comment #5) > Might be a different bug because > https://ta.wikipedia.org/wiki/Special:Log/Bawolff?uselang=en doesn't show > anything, nor does > https://ta.wikipedia.org/w/index. > php?title=சிறப்பு%3ALog&uselang=en&page=User%3ABawolff so it's not clear > whether that account was automatically created as well. > In both cases, [[Special:CentralAuth]] doesn't show the unattached accounts > at all. Now it does, but of course the log entry is still missing. I doubt many sleepless nights will be caused by this absence. Hopefully, this was fixed for good, at bug 39996. (Kunal Mehta (Legoktm) on bug 39996 comment #93) > There have been no new broken accounts since Sept 5th (possibly earlier). > Yay! > > Closing this as fixed, but I'll keep an eye on it to make sure it doesn't > come back. *** This bug has been marked as a duplicate of bug 39996 ***
