Since April 2010,[1] when no lgtoken is passed to the Action API action=login it will return a "NeedToken" response including the token to use. While this method of fetching the login token was deprecated in January 2016,[2] it is still present for the benefit of clients that have not yet been updated and is not (yet) being removed.
The NeedToken response was also being returned when an lgtoken was supplied but could not be validated due to session loss. While this made sense back in 2010 when the NeedToken response was the only way to fetch the login token, these days it is mainly confusing[3] and a way for clients with broken cookie handling to wind up in a loop.
With the merge of Gerrit change 586448,[4] the API will no longer return NeedToken when lgtoken was supplied. If the token cannot be validated due to session loss, a "Failed" response will be returned with a message referring to session loss as the problem.
This change should be deployed to Wikimedia sites with 1.35.0-wmf.28 or later, see https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a schedule.
Note that the change HAS NOT been deployed to Wikimedia sites as of the time of this email. If your client's ability to log in broke on 6 April 2020, the cause is most likely an unrelated change to Wikimedia's infrastructure that caused some HTTP headers to be output with HTTP/2 standard casing, i.e. "set-cookie" rather than the traditional "Set-Cookie". See https://phabricator.wikimedia.org/T249680 for details and further discussion of that situation.
[1]: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/64677 [2]: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/00... [3]: https://phabricator.wikimedia.org/T249526 [4]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/586448
Thanks I’ll go in very soon and correct it take care be safe Michael
Get Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: Cloud cloud-bounces@lists.wikimedia.org on behalf of Brad Jorsch (Anomie) bjorsch@wikimedia.org Sent: Wednesday, April 8, 2020 12:31:34 PM To: mediawiki-api-announce@lists.wikimedia.org mediawiki-api-announce@lists.wikimedia.org Subject: [Cloud] [Mediawiki-api-announce] Change to action=login response when login fails due to session loss
Since April 2010,[1] when no lgtoken is passed to the Action API action=login it will return a "NeedToken" response including the token to use. While this method of fetching the login token was deprecated in January 2016,[2] it is still present for the benefit of clients that have not yet been updated and is not (yet) being removed.
The NeedToken response was also being returned when an lgtoken was supplied but could not be validated due to session loss. While this made sense back in 2010 when the NeedToken response was the only way to fetch the login token, these days it is mainly confusing[3] and a way for clients with broken cookie handling to wind up in a loop.
With the merge of Gerrit change 586448,[4] the API will no longer return NeedToken when lgtoken was supplied. If the token cannot be validated due to session loss, a "Failed" response will be returned with a message referring to session loss as the problem.
This change should be deployed to Wikimedia sites with 1.35.0-wmf.28 or later, see https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmaphttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mediawiki.org%2Fwiki%2FMediaWiki_1.35%2FRoadmap&data=02%7C01%7C%7Ce1f09e3dc49643db9d2308d7dc303bc8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637219972022214386&sdata=4gqq%2FYSHFcRz9GAuNWRAshXiyTpLseqyYyisVU3wHAw%3D&reserved=0 for a schedule.
Note that the change HAS NOT been deployed to Wikimedia sites as of the time of this email. If your client's ability to log in broke on 6 April 2020, the cause is most likely an unrelated change to Wikimedia's infrastructure that caused some HTTP headers to be output with HTTP/2 standard casing, i.e. "set-cookie" rather than the traditional "Set-Cookie". See https://phabricator.wikimedia.org/T249680https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphabricator.wikimedia.org%2FT249680&data=02%7C01%7C%7Ce1f09e3dc49643db9d2308d7dc303bc8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637219972022224397&sdata=shM9hnpbXlf%2BCHmI9J0K8XziJXOExzEhchh283z8jcM%3D&reserved=0 for details and further discussion of that situation.
[1]: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/64677https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mediawiki.org%2Fwiki%2FSpecial%3ACode%2FMediaWiki%2F64677&data=02%7C01%7C%7Ce1f09e3dc49643db9d2308d7dc303bc8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637219972022224397&sdata=lH1IQRMnPIxKlPjawsMVpTGtg3z2HPx8Le%2BMY%2B6EBGc%3D&reserved=0 [2]: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/00...https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.wikimedia.org%2Fpipermail%2Fmediawiki-api-announce%2F2016-January%2F000102.html&data=02%7C01%7C%7Ce1f09e3dc49643db9d2308d7dc303bc8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637219972022234403&sdata=PveZNGjcaErazclJR3UPM7czc2GzlM3j4NEuOyeHVZ0%3D&reserved=0 [3]: https://phabricator.wikimedia.org/T249526https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphabricator.wikimedia.org%2FT249526&data=02%7C01%7C%7Ce1f09e3dc49643db9d2308d7dc303bc8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637219972022244414&sdata=k2w%2FW4La8BDVchll7p4jWvhyhCzX%2BqFkIU0MBF1R8fI%3D&reserved=0 [4]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/586448https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.wikimedia.org%2Fr%2Fc%2Fmediawiki%2Fcore%2F%2B%2F586448&data=02%7C01%7C%7Ce1f09e3dc49643db9d2308d7dc303bc8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637219972022254419&sdata=PyKNGSmO%2Ftjoj2VuXpR6tVK%2FZzlU0m54%2FouLd1b9%2F5o%3D&reserved=0
-- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation