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 ?

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