See I2793a3f2dd64a4bebb0b4d065e09af1e9f63fb89. Current method (action=tokens) will still work, but emits deprecation notices.
Description
Details
- Reference
- bz70059
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
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 |
Event Timeline
Change 223572 had a related patch set uploaded (by M4tx):
Update mw.Api so it uses new token handling
Raising priority because this is causing problems with newer token types not supported in the hardcoded list of the now-deprecated action=tokens API.
See T88044 and https://gerrit.wikimedia.org/r/242050, in which getToken("rollback"); fails.
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.
The problem was that it hardcoded specific core token types, so extension API endpoints that should use csrf with meta=tokens broke.
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.
Change 250601 had a related patch set uploaded (by Krinkle):
[WIP] mediawiki.api: Use action=query&meta=tokens instead of action=tokens
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):
"centralauth",
For meta.wikimedia.org:
"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.
Change 250601 merged by jenkins-bot:
mediawiki.api: Use action=query&meta=tokens instead of action=tokens
Change 223572 abandoned by Legoktm:
Update mw.Api so it uses new token handling
Reason:
Implemented in 298cf413dbc3fa4ee750758e7272ca401da4862c