Page MenuHomePhabricator

Auto-login is creating accounts
Closed, DeclinedPublic

Description

Special:AutoLogin is creating local accounts and merging them when they don't exist. It's not meant to do that. It's causing problems in conjunction with T16862, i.e. total breakage of Special:RenameUser. It also floods the logs. This is apparently a regression.

Actual behavior

  1. user registers on ru.wiki: local and global account are created;
  2. user logins on wikimania wiki and the local account is automatically created;
  3. as a side effect, 13 accounts are created at the same moment on all English and multilingual wikis.

Expected behavior
Step 3 does not happen.


See also: not to be confused with T21161: Don't autologin if local account doesn't exist (don't autocreate if user doesn't explicitly login)

Details

Reference
bz16864

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:28 PM
bzimport set Reference to bz16864.
bzimport added a subscriber: Unknown Object (MLST).

It does not seem to do that always, or not for all users. At least, it has not created an account for me on en.wikiquote.org or on wikispecies, etc.

mike.lifeguard+bugs wrote:

(In reply to comment #0)

Special:AutoLogin is creating local accounts and merging them when they don't
exist. It's not meant to do that. It's causing problems in conjunction with bug
14862, i.e. total breakage of Special:RenameUser. It also floods the logs. This
is apparently a regression.

I'm pretty sure it is supposed to create accounts automatically when you're logged in and visit wikis where you don't have an account yet (and where you already have an account, you should be logged in). If that's not what's happening, you'll have to be clearer.

It's also unclear to me how this breaks RenameUser, or how it's related to bug 14862.

Flooding the logs is the only information I understand here & I don't see how that's a big concern.

(In reply to comment #2)

(In reply to comment #0)

Special:AutoLogin is creating local accounts and merging them when they don't
exist. It's not meant to do that. It's causing problems in conjunction with bug
14862, i.e. total breakage of Special:RenameUser. It also floods the logs. This
is apparently a regression.

I'm pretty sure it is supposed to create accounts automatically when you're
logged in and visit wikis where you don't have an account yet (and where you
already have an account, you should be logged in).

No it's not. You realise I wrote most of it, right?

It's also unclear to me how this breaks RenameUser, or how it's related to bug

That's because I wrote this bug report with an assumption of audience familiarity with the software in question.

(In reply to comment #2)

I'm pretty sure it is supposed to create accounts automatically when you're
logged in and visit wikis where you don't have an account yet (and where you
already have an account, you should be logged in). If that's not what's
happening, you'll have to be clearer.

Those wikis were never visited! They are automatically (per software) merged with the accounts which causes extra work for crats to rename and the account owners to request for renaming.

Regards
DerHexer

mike.lifeguard+bugs wrote:

(In reply to comment #4)

(In reply to comment #2)

I'm pretty sure it is supposed to create accounts automatically when you're
logged in and visit wikis where you don't have an account yet (and where you
already have an account, you should be logged in). If that's not what's
happening, you'll have to be clearer.

Those wikis were never visited! They are automatically (per software) merged
with the accounts which causes extra work for crats to rename and the account
owners to request for renaming.

Regards
DerHexer

That's the information I was looking for; thanks.

Special:AutoLogin on the wiki in question is indeed requested by the browser, otherwise it wouldn't work, would it? So the wiki is visited in that sense. But the user is not aware of it.

(In reply to comment #3)

That's because I wrote this bug report with an assumption of audience
familiarity with the software in question.

*raises hand from clueless audience to confirm*

Human-readable translation:

  1. user registers on ru.wiki: local and global account are created;
  2. user logins on wikimania wiki and the local account is automatically created;
  3. as a side effect, 13 accounts are created at the same moment on all English and multilingual wikis.

(3) is the bug.
Example: https://meta.wikimedia.org/wiki/Special:CentralAuth/Awas1995

Funnier example: https://toolserver.org/~pathoschild/stalktoy/?target=Nemo+quater
It seems that on 2012-04-27 16:48 I logged in on a wiki, a local account was autocreated on 9 more and among these 1 (enwiki) is unattached per bug 29234 (and friends).

Steps as in comment 7 now produce a slightly different result: in step (3) an account was created only on one wiki, the en subdomain of the domain where I registered in step (1).
[[Special:CentralAuth/Bug 16864 test]]

This needs to be retested because currently autocreation/autologin looks broken, I had to explicitly login even on autologin wikis like Wikisource and Wiktionary in another language.

With the SUL rework (and the fix in gerrit 84998), this no longer should happen. Users get a top-level session cookie for the project when they run the autologin code, but don't have an account created until they actually visit the the wiki in the project.

I never found time to spend a few hours trying to reproduce this bug in a way satisfactory to the devs' needs, but it's clearly not fixed. Just look at the automatic account creations on Wikiversity (lowest traffic English site), a hundred per hour: https://en.wikiversity.org/wiki/Special:Log/newusers
The typical example has 11 accounts created at once in the same minute on all English language projects, evidently upon login to one of them: [[Special:CentralAuth/Simonfransila]].

See T74469#1172639 for an example (the task has reproduction steps).

Account autocreation is triggered from CentralAuth's UserLoadFromSession hook handler, i.e. any type RequestContext::getUser() lazy-loads the user. The autologin code itself avoids that, but any hook handler anywhere with an access to the context could potentially trigger it. Probably the easiest way to chase it down is to just log the stack trace from the account autocreation code for a short while.

Tgr set Security to None.
In T74469#1403884, @Tgr wrote:

THat bug is only triggered when you visit multiple wikis or stick around for 30+ days. Most people who register an account probably don't do that.

It was not so in the typical example:

[[Special:CentralAuth/Simonfransila]].

The last two registrations I see in Meta are simply the result of the user logging in on another wiki, e.g. https://meta.wikimedia.org/wiki/Special:CentralAuth/Kombatgod

I wonder if looking at DBPerformance.log would be helpful, since that might have UserLoadFromSession traces already.

Recent example: https://www.mediawiki.org/wiki/Special:CentralAuth/Subhaashchandra

  1. registers on one Wikipedia, gets autocreated on 3 multilingual wikis instantly;
  2. logs in (or does something else?) on 1 other wiki, gets autocreated in 10 more.

Be it at 1st or 2nd login ever, accounts get autocreated on 13-14 wikis they never visited, of which few make sense (loginwiki, ok; metawiki, perhaps needed by CentralNotice or something but in that case it's a bug).

Autocreations on metawiki, mediawikiwiki and loginwiki is now intentional. (1)

MarcoAurelio changed the task status from Open to Stalled.Sep 19 2015, 5:14 PM
MarcoAurelio subscribed.

What @Glaisher said, plus @tstarling is this still happening?

I saw it happen when logging in without javascript-- e.g.,

  1. Create account on enwiki
  2. logout
  3. login to enwiki with javascript disabled
  4. auto-login with type=1x1 to connected wikis
  5. user shows up in creation log
Nemo_bis changed the task status from Stalled to Open.Sep 22 2015, 5:54 AM

I already confirmed above that it's still happening.

Right now the excess autocreation seems limited to mediawikiwiki and metawiki (in addition to the source wiki and loginwiki). See an example https://meta.wikimedia.org/wiki/Special:CentralAuth/Felix.s.eriksson from https://login.wikimedia.org/wiki/Special:Log/newusers and a test with registration on one wiki and then login on another: https://meta.wikimedia.org/wiki/Special:CentralAuth/201603Prova1

Right now the excess autocreation seems limited to mediawikiwiki and metawiki (in addition to the source wiki and loginwiki). See an example https://meta.wikimedia.org/wiki/Special:CentralAuth/Felix.s.eriksson from https://login.wikimedia.org/wiki/Special:Log/newusers and a test with registration on one wiki and then login on another: https://meta.wikimedia.org/wiki/Special:CentralAuth/201603Prova1

I think that's a good thing? For those wikis, we automatically create the account when the account is first created,

	// Create some local accounts as soon as the global registration happens
	$wgCentralAuthAutoCreateWikis = array( 'loginwiki', 'metawiki' );
	if ( $wmfRealm === 'production' ) {
		$wgCentralAuthAutoCreateWikis[] = 'mediawikiwiki';
	}

We create on loginwiki at the request of stewards, and to make the login flow more predictable. Both meta and mediawikiwiki were for OAuth use, although we could probably stop autocreating on mediawikiwiki since we moved the central OAuth wiki.

I agree with @csteipp that it seems everything is going well now. Please keep Meta on the autocreation thing, as it helps stewards too. Thanks.

Glaisher raised the priority of this task from Low to High.May 13 2016, 12:39 PM

Raising priority as this might be the culprit for T119736 (which is breaking user logins and throwing exceptions at other user facing places).

To clarify, I meant that ghost-autocreations by this bug are only half-completing for that bug to be triggered.

Raising priority as this might be the culprit for T119736 (which is breaking user logins and throwing exceptions at other user facing places).

Not really; this happens deterministically every time someone logs in on a new wiki family, and that bug is very sporadic. Also, auto-login is creating accounts on the English and multilingual wikis, and the missing accounts in T119736 are on various small wikis.

Glaisher lowered the priority of this task from High to Medium.May 13 2016, 12:54 PM

Are we sure that this happens only for English and multilingual wikis?

Are we sure that this happens only for English and multilingual wikis?

If not, that would be a bug on top of the original bug (and a very unlikely one). In certain situations CentralAuth tries to log you in on all English / multilang wikis (that's what the little site icons are for on the login page, their source is actually a special page on the target wiki), and that triggers the autocreation. Only one wiki per second-level domain name is needed, that's why it is limited to English.

taavi subscribed.

There's no such thing as Special:AutoLogin currently, and I have not seen the behaviour in the task description happening.

Tgr changed the task status from Invalid to Declined.Jul 24 2023, 2:49 AM

It's called Special:CentralAutoLogin now.

AFAIK the task still correctly describes what CentralAuth tries to do when the user first visits another wiki after creating their account. It just usually fails, because autologin in general ususally fails (T226797: CentralAuth login session and auto-login no longer work across wikis in Safari and Firefox etc).

Auto-attaching newly created local accounts is normal today, while in 2009 it was still an open question who gets which local account, so I don't think we care about it anymore, though (feel free to reopen if you disagree, I don't have a strong opinion on it).

If we do care, we need to check in the createSession step of the autologin sequence whether we are on the initating wiki or an edge wiki, and abort if it's edge wiki, not listed in $wgCentralAuthAutoLoginWikis, and the user's account doesn't exist locally. The only nontrivial part of that is telling whether we are on the initiating wiki - I think we can just check the wiki URL parameter, not sure how reliable it is though.