Page MenuHomePhabricator

OAuth: API calls shouldn't fail when the username does not exist locally
Closed, ResolvedPublicBUG REPORT

Description

When removing Category:Wp/olo on olo.wikipedia.org (a relict left from importing the site from incubator), the bot systematically fails and abort if the page where the category is to be removed has an interwiki link (old-style, not wikidata) and the bot account is not registered on that site. I'm not sure if that's the desired behaviour.

WARNING: API error mwoauth-invalid-authorization-invalid-user: The authorization headers in your request are for a user that does not exist here
ERROR: Fatal error:
Traceback (most recent call last):
  File ".\scripts\category.py", line 1282, in main
    bot.run()
  File ".\scripts\category.py", line 574, in run
    self._change(pagegenerators.CategorizedPageGenerator(self.oldcat))
  File ".\scripts\category.py", line 615, in _change
    sortKey=self.keep_sortkey)
  File "F:\MWDEV\pywikibot-core\pywikibot\page.py", line 2073, in change_category
    newtext = textlib.replaceCategoryLinks(oldtext, cats)
  File "F:\MWDEV\pywikibot-core\pywikibot\textlib.py", line 1246, in replaceCategoryLinks
    interwiki = getLanguageLinks(s2, insite=site)
  File "F:\MWDEV\pywikibot-core\pywikibot\tools\__init__.py", line 1447, in wrapper
    return obj(*__args, **__kw)
  File "F:\MWDEV\pywikibot-core\pywikibot\textlib.py", line 856, in getLanguageLinks
    result[site] = pywikibot.Page(site, pagetitle)
  File "F:\MWDEV\pywikibot-core\pywikibot\tools\__init__.py", line 1447, in wrapper
    return obj(*__args, **__kw)
  File "F:\MWDEV\pywikibot-core\pywikibot\tools\__init__.py", line 1447, in wrapper
    return obj(*__args, **__kw)
  File "F:\MWDEV\pywikibot-core\pywikibot\page.py", line 2178, in __init__
    super(Page, self).__init__(source, title, ns)
  File "F:\MWDEV\pywikibot-core\pywikibot\page.py", line 160, in __init__
    self._link = Link(title, source=source, defaultNamespace=ns)
  File "F:\MWDEV\pywikibot-core\pywikibot\page.py", line 4939, in __init__
    self._defaultns = self._source.namespaces[defaultNamespace]
  File "F:\MWDEV\pywikibot-core\pywikibot\site.py", line 1014, in namespaces
    self._namespaces = NamespacesDict(self._build_namespaces())
  File "F:\MWDEV\pywikibot-core\pywikibot\site.py", line 2610, in _build_namespaces
    is_mw114 = MediaWikiVersion(self.version()) >= MediaWikiVersion('1.14')
  File "F:\MWDEV\pywikibot-core\pywikibot\site.py", line 2717, in version
    version = self.siteinfo.get('generator', expiry=1).split(' ')[1]
  File "F:\MWDEV\pywikibot-core\pywikibot\site.py", line 1676, in get
    preloaded = self._get_general(key, expiry)
  File "F:\MWDEV\pywikibot-core\pywikibot\site.py", line 1622, in _get_general
    default_info = self._get_siteinfo(props, expiry)
  File "F:\MWDEV\pywikibot-core\pywikibot\site.py", line 1548, in _get_siteinfo
    data = request.submit()
  File "F:\MWDEV\pywikibot-core\pywikibot\data\api.py", line 2342, in submit
    self._data = super(CachedRequest, self).submit()
  File "F:\MWDEV\pywikibot-core\pywikibot\data\api.py", line 2175, in submit
    % (self.site, info))
pywikibot.exceptions.NoUsername: Failed OAuth authentication for wikipedia:hif: The authorization headers in your request are for a user that does not exist here
F:\MWDEV\pywikibot-core>

Thank you.

Event Timeline

@Ladsgroup Maybe your "Dexbot" could be run on olowiki so old interwiki links are added/migrated to Wikidata, while we await resolution on this one? (olowiki is now part of the global bot policy so Dexbot edits won't be a problem there). Thanks!

I suppose that this problem does not concern only category.py, I've the same with one of my own script that work on translations, that do API requests of Wikipedias on various languages.

Framawiki renamed this task from category.py with OAuth: don't abort if the username does not exist on other project to OAuth: don't abort if the username does not exist on project.Apr 17 2017, 5:47 PM
Framawiki edited projects, added: Pywikibot-OAuth; removed: Pywikibot-category.py.
Xqt triaged this task as Medium priority.Jul 31 2019, 7:27 PM
Xqt changed the subtype of this task from "Task" to "Bug Report".

Change 528085 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/core@master] Allow basic grant holders to autocreate accounts

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

Change 528085 merged by jenkins-bot:
[mediawiki/core@master] Allow basic grant holders to autocreate accounts

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

Just to be clear about the intended solution to this problem: we're supposed to autocreate the local account in this case, right?

Tgr renamed this task from OAuth: don't abort if the username does not exist on project to OAuth: API calls shouldn't fail when the username does not exist locally.May 25 2026, 2:21 PM

In theory the session provider autocreates as needed. So it's probably one of three issues:

  1. some logic in the OAuth session provider incorrectly assumes that the user exists locally
  2. autocreation fails e.g. because of an abuse filter
  3. autocreation actually works but the request fails anyway because of replication lag

The first one should be an easy fix if it's indeed the case.

The second one is not really fixable, but it would be nice to 1) ensure it will never result in a valid anonymous request, 2) somehow communicate the issue to the user. I'm thinking SessionProvider could have a callback that's called after autocreation from the session, and that could generate an API error.

The third one is not a big deal because the next request will succeed, but also not too hard to fix probably - just need to make sure that all attempts to load a user fall back to the primary on miss.

In theory the session provider autocreates as needed.

I added some logging to that code to find out why it fails. There are at least 3 different issues:

  1. OAuth forbids users that don't exist locally. https://gerrit.wikimedia.org/g/mediawiki/extensions/OAuth/+/f45732da9b55385c9d92d8f31defecb0276163f0/src/SessionProvider.php#184
  2. The user must have permission to (auto)create acounts, and since session restrictions are checked, and most OAuth clients don't have that permission, it will be disallowed.
  3. CentralAuth forbids other auth providers from autocreating accounts. https://gerrit.wikimedia.org/g/mediawiki/extensions/CentralAuth/+/e54a69351f95681fa4dee4d1437312d07e0dc3a4/includes/CentralAuthPrimaryAuthenticationProvider.php#472

After bypassing these 3 problems with some hacky code, autocreation worked for me locally, but we'll need to figure out why these limitations exist, then find nice ways to remove them (problem 2 seems particularly tricky).

Is problem 2 related to autocreate=True parameter of pywikibot.site.login? I think it's reasonable to expect users would pass it (at least I did pass it and still got errors on Wikidata).

Thanks for investigating!

The OAuth error for non-existent users was present from the start (that was pre-Authmanager so I'm not sure how difficult it would have been at the time to autocreate the user), then got lifted into the AuthManager-aware version without any of us thinking about it. I think it's just wrong.

We can probably just add autocreate to the basic grant, it seems harmless enough.

Not sure about CentralAuth, the idea there (I think... it was a while ago) was to prevent other providers which are not central account aware from messing things up, but this doesn't seem like the right way to do it. For autocreate on login it makes sense to disallow when the primary provider doing the login is not CentralAuth (although if that can happen at all, the wiki config probably has bigger problems). For autocreation during session initialization it doesn't make sense - CentralAuth-managed users will always log in via CentralAuth but there's no reason to expect that their sessions are always managed by CentralAuth.

Is problem 2 related to autocreate=True parameter of pywikibot.site.login? I think it's reasonable to expect users would pass it (at least I did pass it and still got errors on Wikidata).

I don't think that's related. You might need to set that to True to take advantage of the fix here, once we fix it (otherwise, if I'm reading the code correctly, Pywikibot will not even attempt to log in if it thinks the account doesn't exist).

@Tgr Thanks. That makes sense. I'll prepare the patches.

Change #1295520 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/CentralAuth@master] Allow other providers to autocreate accounts

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

Change #1295522 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Set default $wgGroupPermissions['*']['autocreateaccount'] to true

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

Change #1295524 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/OAuth@master] Allow autocreation of missing local accounts during OAuth requests

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

Change #1295520 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Allow other providers to autocreate accounts

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

Change #1295522 merged by jenkins-bot:

[mediawiki/core@master] Set default $wgGroupPermissions['*']['autocreateaccount'] to true

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

Change #1295524 merged by jenkins-bot:

[mediawiki/extensions/OAuth@master] Allow autocreation of missing local accounts during OAuth requests

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

Change #1306669 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/OAuth@master] Fix autocreation during OAuth requests for owner-only consumers

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

Change #1306669 merged by jenkins-bot:

[mediawiki/extensions/OAuth@master] Fix autocreation during OAuth requests for owner-only consumers

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