Last modified: 2014-05-22 05:03:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T66727, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 64727 - Bot is getting void edit token after MediaWiki 1.24wmf2 deployment
Bot is getting void edit token after MediaWiki 1.24wmf2 deployment
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.24rc
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
: code-update-regression
Depends on:
Blocks: 64817
  Show dependency treegraph
 
Reported: 2014-05-02 00:27 UTC by -jem-
Modified: 2014-05-22 05:03 UTC (History)
17 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---
bjorsch: Backport_WMF+


Attachments

Description -jem- 2014-05-02 00:27:34 UTC
In some point between 18:38 and 19:05 h UTC, 2014-05-01, something happened that caused my bot ( https://tools.wmflabs.org/guc/?user=Jembot ) to get just "+\" as edit token when requested, after being succesfully logged in, causing it to edit just anonymously. Other bots in es.wikipedia seem to run without any problems. After asking in #wikimedia-tech, it seems that http://en.wikipedia.org/w/api.php?action=tokens&format=json also showing "+\" isn't correct either. Thanks in advance.
Comment 1 Umherirrender 2014-05-02 06:52:55 UTC
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.
Comment 2 Umherirrender 2014-05-02 07:01:59 UTC
(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.
Comment 3 -jem- 2014-05-02 09:42:37 UTC
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
Comment 5 Brad Jorsch 2014-05-02 14:07:53 UTC
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.
Comment 6 Brad Jorsch 2014-05-02 14:17:19 UTC
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.
Comment 7 Gerrit Notification Bot 2014-05-02 14:17:54 UTC
Change 131056 had a related patch set uploaded by Anomie:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131056
Comment 8 Gerrit Notification Bot 2014-05-02 15:54:02 UTC
Change 131056 merged by jenkins-bot:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131056
Comment 9 Brad Jorsch 2014-05-02 16:33:16 UTC
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/
Comment 10 Chris Steipp 2014-05-02 17:24:14 UTC
(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.
Comment 11 Brad Jorsch 2014-05-02 17:26:50 UTC
(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.
Comment 12 Chris Steipp 2014-05-02 17:33:04 UTC
(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?
Comment 13 Brad Jorsch 2014-05-02 17:59:44 UTC
The call on SpecialChangePassword.php line 299 isn't via LoginForm.
Comment 14 Gerrit Notification Bot 2014-05-02 18:32:45 UTC
Change 131105 had a related patch set uploaded by CSteipp:
Maintain remember me state on password change

https://gerrit.wikimedia.org/r/131105
Comment 15 -jem- 2014-05-03 10:33:42 UTC
(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?
Comment 16 Gerrit Notification Bot 2014-05-05 14:28:16 UTC
Change 131471 had a related patch set uploaded by Anomie:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131471
Comment 17 Gerrit Notification Bot 2014-05-05 14:28:47 UTC
Change 131472 had a related patch set uploaded by Anomie:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131472
Comment 18 Gerrit Notification Bot 2014-05-05 15:04:30 UTC
Change 131471 merged by jenkins-bot:
Fix API login after I7c957e1e

https://gerrit.wikimedia.org/r/131471
Comment 19 Gerrit Notification Bot 2014-05-05 15:05:50 UTC
Change 131472 merged by jenkins-bot:
Fix API login after I7c957e1e

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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links