rMW94ba53f67731: Move CSRF token handling into MediaWiki\Session\Session deprecated fetching login and account creation tokens via a NeedToken response from action=login and action=createaccount, in favor of using action=query&meta=tokens. However, attempting to access that on a private wiki results in a "readapidenied" error, because action=query requires read mode even though ApiQueryTokens itself doesn't.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| API: Allow fetching login token from action=query&meta=tokens on private wikis | mediawiki/core | master | +20 -0 |
Related Objects
Related Objects
Event Timeline
Comment Actions
Change 277778 had a related patch set uploaded (by Anomie):
API: Allow fetching login token from action=query&meta=tokens on private wikis
Comment Actions
Change 277778 merged by jenkins-bot:
API: Allow fetching login token from action=query&meta=tokens on private wikis
Comment Actions
Before this fix, ...
Was it possible to log on using the API to a private wiki?
If so, did that involve using a deprecated API?
If so, which released versions are affected?
Does this fix need to be backported?
i.e. from a client perspective (such as pywikibot), when trying to access a private wiki with a version before this fix ... what did they need to do? what should they need to do?
Comment Actions
The above linked login change which introduce the bug was part of the SessionManager which was part of 1.27.0-wmf.12, this fix is now part of 1.27.0-wmf.18, so no release seems affected from this bug, no need for backport.
The easiert way to handle this is to fallback to deprecated login with NeedToken, when getting an readapidenied error from meta=tokens in a MediaWiki with a version of 1.27.0.
Comment Actions
Great! Thanks for clarifying so I didnt need to figure that out.
The easiert way to handle this is to fallback to deprecated login with NeedToken, when getting an readapidenied error from meta=tokens in a MediaWiki with a version of 1.27.0.
OK, I'll look into that. As it isnt a released bug, it might instead be simpler to blacklist using private wikis with -wmf.12 to 17 - it will become a very rare scenario quite quickly.