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(a)wikimedia.org> wrote:
On Mon, Oct 17, 2016 at 11:38 PM, Nicolas Vervelle
<nvervelle(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api