|Open||aaron||T88445 MediaWiki active/active datacenter investigation and work (tracking)|
|Open||None||T92357 Fix problematic database master queries performed on HTTP GET/HEAD|
|Open||None||T46602 Require POST for all changes; Never change content on HEAD-request|
|Duplicate||Krinkle||T33270 Proper AJAX rollback functionality in core|
|Duplicate||None||T49782 Rollback workflow needs further thought|
|Stalled||None||T88044 Make rollback use POST instead of GET (use AJAX in GUI)|
|Resolved||Krinkle||T72059 Update mediawiki.api for new API token handling|
|Resolved||Nikerabbit||T117797 Translate extension should not depend on deprecated ApiTokens module|
- Mentioned Here
- rMW298cf413dbc3: mediawiki.api: Use action=query&meta=tokens instead of action=tokens
rMWaacdb664a10d: mediawiki.api: Use action=query&meta=tokens instead of action=tokens
T74094: mw.api.getToken should not use deprecated api.php?action=tokens
T88044: Make rollback use POST instead of GET (use AJAX in GUI)
Raising priority because this is causing problems with newer token types not supported in the hardcoded list of the now-deprecated action=tokens API.
Per @Anomie (T74094#1470837), we need to know what was wrong with https://gerrit.wikimedia.org/r/166872 (rMWaacdb664a10d: mediawiki.api: Use action=query&meta=tokens instead of action=tokens) so that we can resolve this bug.
Chances are that the JS code can look at /w/api.php?action=paraminfo&modules=tokens|query+tokens and assume that anything accepted by action=tokens but not by action=query&meta=tokens should be mapped to "csrf".
As for "userrights" and "rollback", the old versions of those were accessed via action=query&list=users&ustoken=userrights and action=query&prop=revisions&rvtoken=rollback, respectively. Getting rid of that oddity was one of the reasons for new token handling.
BTW, if you know the module in question (e.g. "block" or "flow+close-open-topic"), you can fetch the token type needed from action=paraminfo.
Proposed change https://gerrit.wikimedia.org/r/250601 has a hardcoded legacy map for the built-in ApiToken types: 'edit', 'delete', 'protect', 'move', 'block', 'unblock', 'email', 'import', 'options'.
For en.wikipedia.org (Types in ApiTokens that are not in ApiQueryTokens):
"aggregategroups", "centralauth", "groupreview", "translatesandbox", "translationreview", "translationstash",
- centralauth: Not needed. This token type is deprecated and can't be migrated because it is conceptually incompatible with the new token system in MediaWiki because it requires session-based token generation that is cached somewhere (not based on simple salts). Its replacement is a separate action API that is already in production. Once callers via mediawiki.api are updated we can go ahead without it.
- Translate extension (all others): Not needed. It implements both old types for older MediaWiki versions and uses standard csrf type for current MediaWiki. However it doesn't support compatibility with clients. Its APIs is only consumed by the front-end of the extension. It supports the old tokens only if the MediaWiki install is MediaWiki 1.24 or earlier. It registers both token hooks, but only the new one works (since ApiBase no longer uses getTokenSalt, so it only validates csrf for Translate APIs). I've recommend Nikerabbit to only register the old hook in the old install to avoid confusion.
Searching through all Wikimedia Git repositories I find no other extensions using the deprecated ApiTokensGetTokenTypes hook.