Currently, all available tokens can be fetched by calling (in series):
From the perspective of a bot library, it would be great if this could be done in one step – that is, the latter could provide an option to fetch all types of tokens without having to first fetch the list of token types.
Change 733948 had a related patch set uploaded (by SD0001; author: SD0001):
[mediawiki/core@master] Allow retrieval of tokens of all available types in one request
Change 734326 had a related patch set uploaded (by SD0001; author: SD0001):
[mediawiki/core@master] Allow retrieval of tokens of all available types in one request
Change 734326 abandoned by SD0001:
[mediawiki/core@master] Allow retrieval of tokens of all available types in one request
Reason:
Dupe of 733948. Created from git review accident
Change 733948 merged by jenkins-bot:
[mediawiki/core@master] Allow retrieval of tokens of all available types in one request
@SD0001 I'm curious, what is the use case for a framework to unconditionally fetch all available types? Why would a bot want this feature in a framework?
Bot frameworks generally build token caches to allow the user to write API calls like: api.post({ ...., token: tokenCache.get('csrf') }), so they don't have to fetch a token before each request. It's easier to refresh this cache in one request rather than go through the more complicated flow mentioned in OP.
Also, when a request fails due to an expired token, a good framework would handle it this way:
That's 4 API requests in series, which is slow – especially if this is an action done in a webservice with the end-user waiting. To speed things things up a bit, we could parallelize 2 and 3 – but this only works correctly if there's a way to fetch tokens of all types.