Page MenuHomePhabricator

Most authentication providers are disabled during autocreation on local domain (SUL3 mode)
Closed, ResolvedPublic

Description

In SUL3 mode, on the local domain, CentralAuth disables most authentication providers via the AuthManagerFilterProviders hook. For login / signup this has the intended effect, since they just redirect to the central domain, and the providers run there; but these providers are also called on autocreation, which cannot redirect. So a side effect of SUL3 is that autocreations which were previously blocked by an authentication provider (e.g. SpamBlacklist) aren't blocked anymore.

In practice this might be fine. Trying to prevent a user from having a local account on some wikis while they already have one on other wikis is not a particularly useful thing to do. It means the user will automatically get logged-out pageviews on that wiki and that wiki alone, which is confusing to say the least. But some wikis did use it, via AbuseFilter, to prevent usernames which are fine in general but not useful on that specific wiki (e.g. because most users of the wiki are unfamiliar with the script it is written in). So maybe that will require some sort of support.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

If we want to change this back, the easiest option is probably to split the relevant authentication providers into a separate autocreation-only and normal-authentication-only part, and then allow the autocreation-only part on the local domain.

We could also change AuthManager to use a different set of providers for autocreation, but that seems much more fragile; autocreation is a part of login, and a provider being called in some checks but not other checks in the same authentication flow would be unexpected, and might cause it to break.

It's also worth pointing out that an abuse filter, for example, won't necessarily disallow the autocreation -- it could just log it. That makes

Trying to prevent a user from having a local account on some wikis while they already have one on other wikis is not a particularly useful thing to do

kind of a red herring.

(And for the record I disagree with that principle anyway, but I'm not going to rehash the arguments I already made in T354487 about that)

it could just log it

Log and tag-only filters should ideally be fired after all consequences are completed (in this case account is created and all synchronous hooks are fired). See T277285: Run non-blocking filters after the edit, as a job

Krinkle renamed this task from Most authentication providers are disabled during autocreation on SUL3 wikis to Most authentication providers are disabled during autocreation on local domain (SUL3 mode).May 9 2025, 1:34 PM

I think it's easier to restore the pre-SUL3 status quo than to try something like T354487: Apply local policy during CentralAuth autocreation as a "block" (logged-in) instead of "prevent" (logged-out), even aside from having to discuss that change. Providers being able to prevent autocreation makes sense in general, because in general autocreation can make something akin to registration. If a wiki uses e.g. GoogleLogin then anyone who has a Google account can log in successfully, and you can't apply filters during login, so autocreation is the only point at which username policies can be applied. CentralAuth is special in that there's a remote identity provider which is not really remote, and can be relied on to enforce the mostly same anti-abuse rules as the local wiki; in the case of a remote identity provider that isn't like that, autocreation log spam is more of a concern. More importantly, a successful autocreation means read access on a private wiki.
So while that proposal makes sense for CentralAuth wikis, it doesn't make sense for MediaWiki generally. And while we could change autocreation checks in core, I don't think CentralAuth can easily prevent other providers from preventing autocreation.

Actually, we added a canAlwaysAutocreate flag for session providers a while ago. The value of that flag gets passed to providers, and mostly they ignore autocreations with that flag (we needed that for NetworkSession). So maybe it would be as easy as setting that flag for CentralAuth sessions? Conceptually that's not very clean, because while some autocreations come from the CentralAuth session provider (because the user visits a wiki where they don't have an account, with a valid CentralAuth parent-domain session cookie), other autocreations come from the CentralAuth authentication provider (because the user logs in on a wiki where they don't have an account) or from custom code in the CentralAuth autologin logic; and conceptually those are unrelated, and someone could use CentralAuth with a different session provider. In practice it would mostly work, though. (Requests with non-CentralAuth session providers, ie. OAuth and bot passwords, would still be blocked from autocreating. So it would definitely be somewhat confusing.)

The other option would be some sort of configuration variable I guess.

Disabling authentication providers also disables post-autocreation callbacks (autoCreatedAccount()). In our case that's fine, nothing but CentralAuth has one (and that one is not disabled).

So I think there are two options, from a technical POV:

  • Restore SUL2 status quo: for all authentication providers which implement testUserForCreation() in a way that's not a noop when $autocreate is true (at a glance that's just AbuseFilter and ClosedWikiProvider), make a copy of them, make the original only act on testUserForCreation() when $autocreate is false, and make the copy only act when $autocreate is true; then allowlist the copy. That's a bit eww but easy to do.
  • Do not allow AbuseFilter to block autocreation: make SessionProvider::canAlwaysAutocreate() default to using some configuration variable, rather than returning false. Set that configuration variable on SUL wikis (but not on the central domain).

Looking at the enwiki abuse logs: https://en.wikipedia.org/wiki/Special:AbuseLog?wpSearchUser=&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=autocreateaccount&wpSearchActionTaken=disallow&wpSearchFilter= filters blocking autocreation happen a few times a month.

And the community is well aware of the consequences that entail: https://en.wikipedia.org/wiki/Wikipedia:Edit_filter_noticeboard/Archive_9#Filters_887_and_890_and_autocreateaccount

So I don't think it's appropriate to turn what seems to have originated as an outright bug into a feature by doing Option 2 there.


Speaking only for myself (and now explicitly against the current consensus of any community) I personally agree with The Anome in that linked discussion, and think there's nothing wrong with communities enforcing their own username policies (or whatever) by using abuse filters to disallow autocreation. But that's not particularly relevant here.

Checking other big wikis, it seems that enwiki is not representative in that case:

Of course, there are multiple log entries from the same accounts there, but the rate is still significantly higher than on enwiki. I also doubt that communities in general are aware of the fact they shouldn't use this approach. I can't recall any message about the fact that SUL3 will prevent such filters from effectively working -- there wasn't any in Tech News or on wikitech-l. I also don't see this mentioned at: https://www.mediawiki.org/wiki/MediaWiki_Platform_Team/SUL3#What_will_change

That said, I perfectly understand the reasons why the approach to just allow autocreation is preferred (and outside of my wiki background, I'd also support it). I do not oppose this solution, but I would rather see a clear message to communities that rely on this feature to prevent from creation of accounts under abusive or even awful names.

Just my 2c in addition to the list above. On it.wiki we are struggling with LTAs who use the trick "register on other wiki projects then autocreate an account on it.wiki". A filter blocking autocreateaccount based on specific patterns was of big help in reducing the successful attempts very close to zero. Between January 2023 (filter creation) up today the filter reacted 13763 times just against this individual LTA. Similar filters covering new patterns linked to that LTA abuser reacted over 3200 times. Note that those filters did not discourage this LTA, but at least saved a lot of work to patroller since the automatic block was enough to provide kind of dam. By the way, this filter was exported upon request to other wikis struggling with the same LTA. One of the typical pattern used, BTW, is using personal street addresses or other sensitive information as part of the username, so they also need suppression.

Now this LTA discovered that blocking on autocreateaccount is no longer reliable. This is just one specific case for it.wiki (look also at the steward chronology for global lock of "Piermark/HoY" socks), saving lot of works and time. We are struggling with at least other four or five similar LTAs with similar compulsive behaviour and blocking autocreation under specific conditions was, so far, one of the most powerful tool we have. I was personally disappointed when I discovered that the abuse filter based on autocreateaccount blocking are no longer relliable.

While I understand the point related to a global view, nevertheless I would prefer a solution that on one side saves SUL3 and on the other side provides a way or a workaround for individual projects to locally enable the blocking on autocreateaccount. Otherwise, if this is not possible, I agree that communities or at least local filter managers (typically, sysops) should be informed that this situation will lead to ineffective filters and additional patrolling workload to cover this new situation.

Change #1148314 had a related patch set uploaded (by D3r1ck01; author: Derick Alangi):

[mediawiki/extensions/CentralAuth@master] Re-enable AbuseFilterPreAuthenticationProvider on local domain

https://gerrit.wikimedia.org/r/1148314

Change #1148314 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Re-enable AbuseFilterPreAuthenticationProvider on shared domain

https://gerrit.wikimedia.org/r/1148314

This goes live this week, we can either test it by creating a test filter, or by checking in Logstash or the AbuseFilter logs that autocreation blocks start happening again.

Just to be sure, I repeated the steps I used locally when testing this change.

  1. Created a filter to prevent account creation on test.wp: https://test.wikipedia.org/wiki/Special:AbuseFilter/286 (accountname contains "T393473")
  2. Registered an account on another wiki (en.wp) and logged in there: https://en.wikipedia.org/w/index.php?title=Special:Log&logid=170078443
  3. Visited yet another wiki (fr.wp) – verified that account was autocreated and I am logged in (normal SUL behavior): https://fr.wikipedia.org/w/index.php?title=Spécial:Journal&logid=111843124
  4. Visited test.wp – verified that I am not logged in (blocked by the filter)
  5. Tried to log in on test.wp – received this error message:
    image.png (1×1 px, 77 KB)

Change #1187980 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[operations/mediawiki-config@master] Allow ClosedWikiProvider on the local domain on SUL wikis

https://gerrit.wikimedia.org/r/1187980

Change #1187980 merged by jenkins-bot:

[operations/mediawiki-config@master] Allow ClosedWikiProvider on the local domain on SUL wikis

https://gerrit.wikimedia.org/r/1187980

Mentioned in SAL (#wikimedia-operations) [2025-09-15T20:49:56Z] <tgr@deploy1003> Started scap sync-world: Backport for [[gerrit:1187476|Allow creating new WebAuthn passkeys on private wikis (T378402 T354701)]], [[gerrit:1187980|Allow ClosedWikiProvider on the local domain on SUL wikis (T393473 T401640)]], [[gerrit:1188420|session: Cache JWT JTI in CookieSessionProvider (T399200)]]

Mentioned in SAL (#wikimedia-operations) [2025-09-15T20:56:19Z] <tgr@deploy1003> tgr: Backport for [[gerrit:1187476|Allow creating new WebAuthn passkeys on private wikis (T378402 T354701)]], [[gerrit:1187980|Allow ClosedWikiProvider on the local domain on SUL wikis (T393473 T401640)]], [[gerrit:1188420|session: Cache JWT JTI in CookieSessionProvider (T399200)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-09-15T21:07:19Z] <tgr@deploy1003> Finished scap sync-world: Backport for [[gerrit:1187476|Allow creating new WebAuthn passkeys on private wikis (T378402 T354701)]], [[gerrit:1187980|Allow ClosedWikiProvider on the local domain on SUL wikis (T393473 T401640)]], [[gerrit:1188420|session: Cache JWT JTI in CookieSessionProvider (T399200)]] (duration: 17m 23s)