That json is not returning token is a feature, see http://en.wikipedia.org/w/api.php?modules=json - "For safety, all user-specific data will be restricted."

You can use the 'assert' param of the main module to be sure, you bot only edits as user and/or bot.

(In reply to Umherirrender from comment #1)

That json is not returning token is a feature, see
http://en.wikipedia.org/w/api.php?modules=json - "For safety, all
user-specific data will be restricted."

Only when callback param is given, not in all cases, so you can use it, but when it gives a anon edit token ('+\'), than there was no login cookies set or there was a failures in the infrastructure or some other things.

I'm still totally stuck with this. But now I'm sure the problem has to do with the MediaWiki 1.24wmf2 deploy: the problem appeared in es.wikinews 29 Apr, 18 h UTC, and in es.wikipedia 1 May, 19 h UTC, matching the times in https://wikitech.wikimedia.org/wiki/Deployments, but I can't see (or don't know how to identify) any related change in https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf2

Also reported in https://commons.wikimedia.org/w/index.php?title=Commons:Forum&oldid=122911031#.C3.84nderung_am_API_Logon.3F

I suspect this may be due to Gerrit change 94614: in 1.24wmf1 API logins are done as if the "keep me logged in" checkbox is checked, but that change appears to have made it set the cookies as if that checkbox is unchecked. I suspect this bot may be settings its cookies in such a way that it was relying on the former behavior.

Looking into it a little more, I wonder if that change also broke "keep me logged in" on new account creation and on password changes. At any rate, I'll fix the API bit of it.

Change 131056 had a related patch set uploaded by Anomie:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131056

Change 131056 merged by jenkins-bot:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131056

The change would normally be deployed with 1.24wmf4 (see https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule), but I've added this to the list to backport during the 15:00 UTC deployment window on Monday.

In the mean time, you might verify whether your bot's login works against http://en.wikipedia.beta.wmflabs.org/

(In reply to Brad Jorsch from comment #6)

Looking into it a little more, I wonder if that change also broke "keep me
logged in" on new account creation and on password changes. At any rate,
I'll fix the API bit of it.

The keep me logged in on account creation was removed sometime before 1.22. The login on password reset uses the LoginForm from Special:UserLogin, and sets the checkbox correctly.

So just the api was affected.

(In reply to Chris Steipp from comment #10)

The keep me logged in on account creation was removed sometime before 1.22.
The login on password reset uses the LoginForm from Special:UserLogin, and
sets the checkbox correctly.

So just the api was affected.

It's not the checkbox, it's that the calls to $user->setCookies() in those two places used to use the user preference (remembered from the last login) and now will always set the cookies as if the checkbox was unchecked.

(In reply to Brad Jorsch from comment #11)

It's not the checkbox, it's that the calls to $user->setCookies() in those
two places used to use the user preference (remembered from the last login)
and now will always set the cookies as if the checkbox was unchecked.

LoginForm passes $this->mRemember to setCookies, which the password-reset login scenario sets up to get set, if the user has checked the box.

For account creation, the checkbox has been removed, so you're right, it's treated as though the user didn't request to stay logged in. Did it previously?

The call on SpecialChangePassword.php line 299 isn't via LoginForm.

Change 131105 had a related patch set uploaded by CSteipp:
Maintain remember me state on password change

https://gerrit.wikimedia.org/r/131105

(In reply to Brad Jorsch from comment #9)

The change would normally be deployed with 1.24wmf4 (see
https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule), but
I've added this to the list to backport during the 15:00 UTC deployment
window on Monday.

In the mean time, you might verify whether your bot's login works against
http://en.wikipedia.beta.wmflabs.org/

I have verified there and it works, thanks. As my bot has maintenance and cleaning tasks every few minutes, I have had to work in another way to edit (libcurl instead of Snoopy), but I'll wait until Monday to recover the rest of functions which require login/tokens. Thanks everyone for the fast help. A final question: as it seems mine was/is not a standard way to handle cookies/tokens, could this problem happen again in the future?

Change 131471 had a related patch set uploaded by Anomie:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131471

Change 131472 had a related patch set uploaded by Anomie:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131472

Change 131471 merged by jenkins-bot:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131471

Change 131472 merged by jenkins-bot:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131472