Re: [Mediawiki-api] [Mediawiki-api-announce] Change to action=login response when login fails due to session loss

2020-04-08 Thread Valerio Bozzolan
Thank you Brad,

And if I can summarize this announce with a bit of irony over our whole IT 
world:

"How to rise problems to the world just changing 2 little... tender... chars. 
Try with 'Set-Cookie' → 'set-cookie' :^)

Happy hacking and thank you again

On April 8, 2020 6:31:34 PM GMT+02:00, "Brad Jorsch (Anomie)" 
 wrote:
>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/000102.html
>[3]: https://phabricator.wikimedia.org/T249526
>[4]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/586448

-- 
E-mail sent from the "K-9 mail" app from F-Droid, installed in my LineageOS 
device without proprietary Google apps. I'm delivering through my Postfix 
mailserver installed in a Debian GNU/Linux.

Have fun with software freedom!

[[User:Valerio Bozzolan]]

___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api


[Mediawiki-api] [Mediawiki-api-announce] Change to action=login response when login fails due to session loss

2020-04-08 Thread Brad Jorsch (Anomie)
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/000102.html
[3]: https://phabricator.wikimedia.org/T249526
[4]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/586448

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api