The Wikibase code just uses a standard ( _api /* new mw.Api() / new mw.ForeignApi() */ ).postWithToken( 'csrf', params ) call (in lib/resources/wikibase-api/src/RepoApi.js, post called from setSitelink called from client/resources/wikibase.client.PageConnector.js), so I doubt this is a Wikibase-specific issue… I see a lot of CentralAuth stuff in the network tab (to ensure that the API request is made logged in on Wikidata), so I wonder if CentralAuth is manipulating the API parameters incorrectly?

Pinging @Tgr and @xSavitar, do you think this could be related to the recent SUL3 work?

Based on the timing of this report and T385249, I suspect this is a regression in wmf.14 (T382365) – it feels like, if it was older, people would have noticed it sooner. The only vaguely relevant-looking commit in gerrit/wmf/1.44.0-wmf.13..gerrit/wmf/1.44.0-wmf.14 that I’ve found so far is CentralAuth: Use abort signals in mw.Api code, which sounds like it should be an unrelated refactoring but does at least touch the ForeignApi code that would be involved in this request…

I don't see any obvious relationship; we didn't change mw.ForeignApi or the centralauthtoken API. Also, I tried and didn't get this error.

I tried to reproduce the issue in isolation, and I can see in the network tab that

await new mw.ForeignApi( 'https://www.wikidata.org/w/api.php' ).postWithToken( 'csrf', { action: 'checktoken', type: 'csrf' } );

(on enwiki:Special:BlankPage) produces a GET request to Wikidata – it’s not just putting the token in the URL, it’s completely dropping the POST method. But that might also be due to the checktoken action.

Unfortunately, the reproduction steps in the task as stated don’t work anymore, because the Danish Wikipedia article has been linked to the Wikidata item in the meantime…

rMW37c52ab4105e: mediawiki.api: Remove console warning for legacy token type is the only recent change touching token handling but it looks like a trivial noop.

In T385261#10511425, @Lucas_Werkmeister_WMDE wrote:

I tried to reproduce the issue in isolation, and I can see in the network tab that

await new mw.ForeignApi( 'https://www.wikidata.org/w/api.php' ).postWithToken( 'csrf', { action: 'checktoken', type: 'csrf' } );

(on enwiki:Special:BlankPage) produces a GET request to Wikidata – it’s not just putting the token in the URL, it’s completely dropping the POST method. But that might also be due to the checktoken action.

Can also reproduce with a real POST action (action=options with a nonexisting option name and no value is a safe no-op):

await new mw.ForeignApi( 'https://www.wikidata.org/w/api.php' ).postWithToken( 'csrf', { action: 'options', optionname: 'T385261' } );

Uncaught (in promise) mustpostparams

And the network panel shows:

GET https://www.wikidata.org/w/api.php?action=options&format=json&origin=https://en.wikipedia.org&centralauthtoken=REDACTED&optionname=T385261&token=REDACTED+\

In T385261#10511425, @Lucas_Werkmeister_WMDE wrote:

Unfortunately, the reproduction steps in the task as stated don’t work anymore, because the Danish Wikipedia article has been linked to the Wikidata item in the meantime…

I have unlinked the Danish Wikipedia article again for testing, but other editors at dawiki might relink it at any time ...

You can check with this one at euwiki: https://eu.wikipedia.org/wiki/Liebenau

In T385261#10511497, @Dipsacus_fullonum wrote:

I have unlinked the Danish Wikipedia article again for testing, but other editors at dawiki might relink it at any time ...

Thanks; I can confirm that the request being made there is also a GET, not a POST. So the issue isn’t really about the token parameter in particular, it’s that the request method is getting completely lost somewhere.

Same issue in ukwiki

The sharing of AJAX options (which include the method) between multiple requests in rECAU4f97b0ccbe14: Use abort signals in mw.Api code seems wrong, but I'd expect that to fail in the other direction, with the method of the centralauthtoken API request being influenced by the method of the main request, not the other way around.

Ah, mw.Api.get apparently modifies the AJAX options object passed to it.

Ah, so CentralAuth (or mw.Api?) should shallow-copy the ajaxOptions to prevent the POST request being turned into a GET request by the other GET requests happening to fetch the CentralAuth token?

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

[mediawiki/extensions/CentralAuth@master] ForeignApi: Do not share AJAX options between requests

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

CentralAuth already takes care to not modify the given ajaxOptions when adding the URL:

newAjaxOptions = Object.assign( {}, ajaxOptions, { url: url } );

So I’m tempted to say this should really be fixed in core; that said, mw.Api has always modified the given ajaxOptions and I have no idea who might rely on that behavior, so it’s probably safer to work around it in CentralAuth… as you’ve done while I was typing this :)

I think mw.Api shouldn't modify the argument in-place but since ForeignApi is the one that recently changed, it's less risky to fix there.

Tested using:

lucaswerkmeister-wmde@mwdebug2002:~$ curl https://gerrit.wikimedia.org/g/mediawiki/extensions/CentralAuth/+/refs/changes/32/1115832/2/modules/ext.centralauth.ForeignApi.js?format=TEXT | base64 -d | sudo -u mwdeploy tee /srv/mediawiki/php-1.44.0-wmf.14/extensions/CentralAuth/modules/ext.centralauth.ForeignApi.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9308    0  9308    0     0  80241      0 --:--:-- --:--:-- --:--:-- 80241

And then loading https://da.wikipedia.org/wiki/Lars_Poulsen_(gr%C3%B8nlandsk_politiker)?debug=2 with WikimediaDebug set to mwdebug2002.codfw.wmnet; this edit was successfully made.

This was the minimum-effort fix, but I think getCentralAuthToken shouldn't use the same ajaxOptions at all, just copy the abort signal directly. It could contain all kinds of stuff (extra headers etc) meant for the main request only.

Change #1115833 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.14] ForeignApi: Do not share AJAX options between requests

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

Yeah, I think that makes sense too.

Change #1115832 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] ForeignApi: Do not share AJAX options between requests

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

Change #1115833 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.14] ForeignApi: Do not share AJAX options between requests

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

Mentioned in SAL (#wikimedia-operations) [2025-01-31T12:28:40Z] <lucaswerkmeister-wmde@deploy2002> Started scap sync-world: Backport for [[gerrit:1115833|ForeignApi: Do not share AJAX options between requests (T385261)]]

Mentioned in SAL (#wikimedia-operations) [2025-01-31T12:31:35Z] <lucaswerkmeister-wmde@deploy2002> lucaswerkmeister-wmde: Backport for [[gerrit:1115833|ForeignApi: Do not share AJAX options between requests (T385261)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-01-31T12:38:30Z] <lucaswerkmeister-wmde@deploy2002> Finished scap sync-world: Backport for [[gerrit:1115833|ForeignApi: Do not share AJAX options between requests (T385261)]] (duration: 09m 49s)

Should be fixed now (you may need to force-reload the page, not sure).

@Tgr do you want to leave the task open for follow-up changes or close it?

Fixed at euwiki. Thanks!