Hi,
I haven't followed the latest modifications on action login, but users of WPCleaner have been complaining for a few days that they couldn't do any modifications through WPCleaner, getting an error message saying that they must be logged in to update pages.
I was away for few days, so I didn't have a chance to look at that before now. After a quick investigation, I found that action login doesn't return a lgtoken in its answer, just a lguserid and a lgusername.
Is it normal that lgtoken is not returned anymore ? What's the correct way to login through the API that won't break again in the next months ?
Thanks for any help Nico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Nicolas,
On 18.10.2016 08:38, Nicolas Vervelle wrote:
Hi,
I haven't followed the latest modifications on action login, but users
of
WPCleaner have been complaining for a few days that they couldn't do a
ny
modifications through WPCleaner, getting an error message saying that
they
must be logged in to update pages.
I was away for few days, so I didn't have a chance to look at that bef
ore
now. After a quick investigation, I found that action login doesn't re
turn
a lgtoken in its answer, just a lguserid and a lgusername.
Is it normal that lgtoken is not returned anymore ? What's the correct
way
to login through the API that won't break again in the next months ?
See deprecation message at: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-August /000115.html
Thanks for any help Nico
On Tue, Oct 18, 2016 at 1:09 PM, Dennis Roczek <dennisroczek@libreoffice.org
wrote:
See deprecation message at: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-August /000115.html
Thanks for the reply, but I don't see anything related to my problem in the post... I do not pass parameters in the POST URI, but it the body, and I don't get any error or warning (except for the deprecation of action=login), it's just that the answer contains lguserid and lgusername but not lgtoken.
Nico
</offlist>
I'm too lazy to search for the archive links: here are the three relevant links which do belong to your problem!
I just picked the newest one without reading the mail again.
Regards,
Dennis
On 18.10.2016 13:38, Nicolas Vervelle wrote:
On Tue, Oct 18, 2016 at 1:09 PM, Dennis Roczek <dennisroczek@libreoffice.org
wrote:
See deprecation message at: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-August /000115.html
Thanks for the reply, but I don't see anything related to my problem in the post... I do not pass parameters in the POST URI, but it the body, and I don't get any error or warning (except for the deprecation of action=login), it's just that the answer contains lguserid and lgusername but not lgtoken.
Nico
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Primary issue is that the login token has been moved to the cookies and not an actual token that needs to be re-used. hopefully that helps.
On Tue, Oct 18, 2016 at 7:40 AM, Dennis Roczek <dennisroczek@libreoffice.org
wrote:
</offlist>
I'm too lazy to search for the archive links: here are the three relevant links which do belong to your problem!
I just picked the newest one without reading the mail again.
Regards,
Dennis
On 18.10.2016 13:38, Nicolas Vervelle wrote:
On Tue, Oct 18, 2016 at 1:09 PM, Dennis Roczek <
dennisroczek@libreoffice.org
wrote:
See deprecation message at: https://lists.wikimedia.org/pipermail/mediawiki-api-
announce/2016-August
/000115.html
Thanks for the reply, but I don't see anything related to my problem in
the
post... I do not pass parameters in the POST URI, but it the body, and I don't
get
any error or warning (except for the deprecation of action=login), it's just that the answer contains lguserid and lgusername but not lgtoken.
Nico
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
---------- Forwarded message ---------- From: "Brad Jorsch (Anomie)" bjorsch@wikimedia.org To: mediawiki-api-announce@lists.wikimedia.org Cc: Date: Tue, 15 Dec 2015 11:11:03 -0500 Subject: [Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: Removal of lgtoken, cookieprefix, and sessionid response values from action=login Long ago, the only mechanism for session management in MediaWiki was certain cookies set by the User class. When ApiLogin was written, in addition to setting these cookies as usual it also returned some of the values needed to construct these cookies on the client. Presumably this was to make things easier for clients that somehow couldn't handle the standard cookie headers.
Then CentralAuth came along. Now, constructing the cookies manually would log you in to the local wiki only, without taking advantage of the SUL mechanism.
Then T55032[1] happened, and clients that were using the manual-construction mechanism had to update their code because one of the cookie names changed and that wasn't part of the data being returned.
And soon, we'll have SessionManager and AuthManager, which will make it possible for login to easily happen in ways that don't involve cookies at all.
So it's time to eliminate the pretense that clients can manually construct the cookies instead of handing the standard HTTP cookie headers. Tentative plan is to deprecate them now and then remove them sometime during 1.28; if anyone objects to this schedule, please raise your concerns in https://phabricator.wikimedia.org/T121527.
-- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation
Mediawiki-api-announce mailing list Mediawiki-api-announce@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
---------- Forwarded message ---------- From: "Brad Jorsch (Anomie)" bjorsch@wikimedia.org To: mediawiki-api-announce@lists.wikimedia.org Cc: Date: Fri, 29 Jul 2016 10:38:02 -0400 Subject: [Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Removal of lgtoken, cookieprefix, and sessionid response values from action=login These response values, deprecated in December 2015, will no longer be returned in the response to action=login. This change should be deployed to WMF wikis with 1.28.0-wmf.13, see https://www.mediawiki.org/ wiki/MediaWiki_1.28/Roadmap for the schedule.
Note that the lgtoken *parameter* to action=login is not removed, nor is the 'token' response value included along with a NeedToken response.
This is expected to have a low client impact, since proper handling of the Set-Cookie headers (rather than manually building cookies using these response values) has been effectively required for some time now.
The original deprecation announcement is quoted below:
On Tue, Dec 15, 2015 at 11:11 AM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
Long ago, the only mechanism for session management in MediaWiki was certain cookies set by the User class. When ApiLogin was written, in addition to setting these cookies as usual it also returned some of the values needed to construct these cookies on the client. Presumably this was to make things easier for clients that somehow couldn't handle the standard cookie headers.
Then CentralAuth came along. Now, constructing the cookies manually would log you in to the local wiki only, without taking advantage of the SUL mechanism.
Then T55032[1] happened, and clients that were using the manual-construction mechanism had to update their code because one of the cookie names changed and that wasn't part of the data being returned.
And soon, we'll have SessionManager and AuthManager, which will make it possible for login to easily happen in ways that don't involve cookies at all.
So it's time to eliminate the pretense that clients can manually construct the cookies instead of handing the standard HTTP cookie headers. Tentative plan is to deprecate them now and then remove them sometime during 1.28; if anyone objects to this schedule, please raise your concerns in https://phabricator.wikimedia.org/T121527.
-- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation
-- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation
Mediawiki-api-announce mailing list Mediawiki-api-announce@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
---------- Forwarded message ---------- From: "Brad Jorsch (Anomie)" bjorsch@wikimedia.org To: mediawiki-api-announce@lists.wikimedia.org Cc: Date: Fri, 19 Aug 2016 15:24:50 -0400 Subject: [Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: Passwords and other sensitive fields for authentication must be in the POST body For improved safety, passwords and other sensitive fields for authentication should not be included in the request URI during a POST. Instead, they should be in the POST body where they are less likely to be included in log files. With the merge of Gerrit change 305545,[1] the API will now produce a warning if such fields are detected in the URI. This should be deployed to WMF wikis with 1.28.0-wmf.16, see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.
This affects the following modules and fields:
- action=login: 'lgpassword'
- action=clientlogin, action=createaccount, action=linkaccount, and action=changeauthenticationdata:
Any fields reported as "sensitive" by action=query&meta=authmanagerinfo or by UI or REDIRECT responses. Currently, this affects the 'password' and 'retype' fields.
The 'lgtoken' field for action=login will now also issue a warning if placed in the request URI. The error code for other tokens being in the request URI has changed from 'mustposttoken' to 'mustpostparams'.
To check if your client's user agent is detected making such submissions, you can also use ApiFeatureUsage[2] and look for '<action>-params-in-query-string' once 1.28.0-wmf.16 is rolled out to wikis your client is logging in to.
It is planned that these warnings will be changed to errors during 1.29. Let's avoid having a repeat of T142155,[3] update your code ASAP instead of waiting until it breaks. Thanks.
-- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation
Mediawiki-api-announce mailing list Mediawiki-api-announce@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
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
On Mon, Oct 17, 2016 at 11:38 PM, Nicolas Vervelle nvervelle@gmail.com wrote:
I haven't followed the latest modifications on action login, but users of WPCleaner have been complaining for a few days that they couldn't do any modifications through WPCleaner, getting an error message saying that they must be logged in to update pages.
I was away for few days, so I didn't have a chance to look at that before now. After a quick investigation, I found that action login doesn't return a lgtoken in its answer, just a lguserid and a lgusername.
Is it normal that lgtoken is not returned anymore ? What's the correct way to login through the API that won't break again in the next months ?
The relevant deprecation announcement is https://lists.wikimedia.org/pipermail/mediawiki-api/2015-December/003677.htm... In short, rely on standard HTTP semantics for cookie handling. WPCleaner is written in Java so this probably means using a CookieManager.
If you haven't been following API deprecation notices for the last ten or so months, https://lists.wikimedia.org/pipermail/mediawiki-api/2016-January/003686.html might also be of interest.
On Tue, Oct 18, 2016 at 4:14 PM, Gergo Tisza gtisza@wikimedia.org wrote:
If you haven't been following API deprecation notices for the last ten or so months, https://lists.wikimedia.org/pipermail/ mediawiki-api/2016-January/003686.html might also be of interest.
More generally, if you haven't been following API deprecation notices then you should subscribe to the mediawiki-api-announce list[1] and look through its archives[2] for the past year or so. There aren't many.
[1]: https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce [2]: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/
[...] you should subscribe to the mediawiki-api-announce list [...]
As far as I can tell, this list is itself subscribed to mediawiki-api-announce@, so I think everyone should already be covered in that respect. :-)
On Tue, Oct 18, 2016 at 3:15 PM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
On Tue, Oct 18, 2016 at 4:14 PM, Gergo Tisza gtisza@wikimedia.org wrote:
If you haven't been following API deprecation notices for the last ten or so months, https://lists.wikimedia.org/pipermail/mediawiki-api/ 2016-January/003686.html might also be of interest.
More generally, if you haven't been following API deprecation notices then you should subscribe to the mediawiki-api-announce list[1] and look through its archives[2] for the past year or so. There aren't many.
-- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Thanks for all the links and pointers to the various announcements.
I fixed the problem in WPCleaner, it was quite simple as I was using the "lgtoken" value as a quick check for ensuring that the user has gone through the login process before calling the API for any page update. The login process was in fact working correctly, it was just an extra verification that created the problem.
I still have to update WPCleaner due to the deprecation of action=login, but I'm not sure yet if I should go for action=clientlogin or for BotPassword.
Nico
On Tue, Oct 18, 2016 at 10:14 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Oct 17, 2016 at 11:38 PM, Nicolas Vervelle nvervelle@gmail.com wrote:
I haven't followed the latest modifications on action login, but users of WPCleaner have been complaining for a few days that they couldn't do any modifications through WPCleaner, getting an error message saying that they must be logged in to update pages.
I was away for few days, so I didn't have a chance to look at that before now. After a quick investigation, I found that action login doesn't return a lgtoken in its answer, just a lguserid and a lgusername.
Is it normal that lgtoken is not returned anymore ? What's the correct way to login through the API that won't break again in the next months ?
The relevant deprecation announcement is https://lists.wikimedia.org/ pipermail/mediawiki-api/2015-December/003677.html In short, rely on standard HTTP semantics for cookie handling. WPCleaner is written in Java so this probably means using a CookieManager.
If you haven't been following API deprecation notices for the last ten or so months, https://lists.wikimedia.org/pipermail/ mediawiki-api/2016-January/003686.html might also be of interest.
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
On Tue, Oct 18, 2016 at 11:45 PM, Nicolas Vervelle nvervelle@gmail.com wrote:
I still have to update WPCleaner due to the deprecation of action=login, but I'm not sure yet if I should go for action=clientlogin or for BotPassword.
Bot password if you store the password, clientlogin if you don't and use interactive login instead.
mediawiki-api@lists.wikimedia.org