|Open||None||T78390 Load volatile information at run-time from the API (tracking)|
|Open||None||T229364 CSRF token issues (tracking)|
|Open||None||T78393 Load token types needed for each API module from the API|
|Resolved||jayvdb||T85725 token methods should use the list of tokens in paraminfo|
- Mentioned In
- T199643: Generate a new CSRF token if the old one is invalidated
T74207: detect write api actions
T61678: Implement badtoken detection and recovery
T85725: token methods should use the list of tokens in paraminfo
- Mentioned Here
- T85725: token methods should use the list of tokens in paraminfo
Okay I've written this comment before I saw Ricordisamoa's comment above… so this comment doesn't make sense anymore.
I'm not sure about which tokens @Ricordisamoa is talking. All tokens accessible via action=tokens, action=query&meta=tokens and action=query&prop=info&intoken=… are now loaded initially. So if an extension is using something else it won't load its tokens but I think that is not feasible. But already before it has been loading all/almost all tokens at once, at least for the WMF wikis I think so maybe I'm missing something. Or it was specifically about that TOKENS_ are outdated but then it'd be a duplicate of T85725: token methods should use the list of tokens in paraminfo.
Ah, so this task would be resolved if api.py automatically added the necessary token, using paraminfo. Then site.py wouldnt need to specify which token to use, and this may even mean site.py adapts better to older versions where the token name is different from the new simplified token system.
That patch might demonstrate it is easy to do 1.21+, but the hard part (pre 1.21) is ignored. If we remove the token related code from site.py , that patch only supports 1.21. If we leave token related code in site.py API calls, then what benefit is there in this patch?