Page MenuHomePhabricator

Cannot login to beta cluster: "There seems to be a problem with your login session..."
Open, HighPublicBUG REPORT

Description

What is the problem?

If I try to login to beta cluster, I see the error message:

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please resubmit the form.

I have tried clearing my cookies, using different browsers, even using Browserstack emulator.

This has occurred so far on https://en.wikipedia.beta.wmflabs.org, https://en.wiktionary.beta.wmflabs.org, https://es.wikibooks.beta.wmflabs.org.

I cannot reproduce this on my local environment, which is the same MediaWiki version as beta.

Steps to reproduce problem
  1. Go to https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin
  2. Attempt to login
Environment

Browser: Firefox, Chromium, Safari
Wiki(s): MediaWiki 1.36.0-alpha (a01f759) 06:56, 23 September 2020

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 23 2020, 7:52 AM
dom_walden updated the task description. (Show Details)Sep 23 2020, 7:57 AM
zeljkofilipin triaged this task as High priority.Sep 23 2020, 8:19 AM

Logging in fails even via the API. From selenium-daily-beta-MediaWiki/782/console:

[0-1] [07:40:51] [E] [MWBOT] Login failed: Selenium user@https://en.wikipedia.beta.wmflabs.org/w

mwbot is an npm package we use to automate the API.

I have just been able to successfully login to https://en.wikipedia.beta.wmflabs.org.

I just got the same problem, and noticed it because the AC/DC browser tests failed (Travis build). But the tests run each day and only started failing today, so it’s a bit confusing to me that this problem was already reported back in September…

Two additional problems which I assume have the same underlying problem as this one:

  • creating an account on CS beta wikipedia fails with "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please resubmit the form."
  • with an account logged-in to English beta wikipedia, calling new mw.Api().saveOptions( {"some-pref": "some-val" } ) fails with "Invalid CSRF token."

Tried to restart cassandra as noted in T243123#6431183, but it still doesn't work.

I can log in in the browser now; the AC/DC browser tests fail (Travis build) with a different message:

Cannot log in when using MediaWiki\Session\BotPasswordSessionProvider sessions.

Tgr added a subscriber: Tgr.Mon, Oct 19, 6:47 PM

I can log in in the browser now; the AC/DC browser tests fail (Travis build) with a different message:

Cannot log in when using MediaWiki\Session\BotPasswordSessionProvider sessions.

That seems unrelated. You can't log in with a bot password via the normal interface; it is for API only. If, in the same browser, you are logged in with a bot password, and trying to use the login page, you get this error, since you have an active session that cannot interact with the login page.

Well, I’m getting that error from the API (action=login). It seems to happen when the session was already logged in (i. e., the first browser test that tries to login succeeds, the second one fails). Is this a new restriction? These browser tests run each day and I haven’t touched the login part in months.

Tgr added a comment.Mon, Oct 19, 7:17 PM

I don't think the login code has changed since 2015. Maybe it's due to the browser failing to log out of the bot session? Logout problems were mentioned above. (In which case, either the Selenium code does not check for logout success status, or the API gives it incorrectly; either way it's a bug, although one only triggered in unusual circumstances.)

Tgr added a comment.Mon, Oct 19, 7:44 PM

There are some big spikes of sessionstore-caused errors like Failed to delete enwikisource:MWSession:abcdef1234567890abcdef1234567890 : (500):


No appname:sessionstore errors though. So there seems to be a whole string of problems here:

  • beta sessionstore seems unstable
  • beta sessionstore does not seem to report to logstash-beta
  • the template for that error message is Failed to delete <key> : ({code}) {error}; sessionstore is apparently returning empty 500 error pages with no message, or MediaWiki fails to parse the error message.
  • <key> in the above message should be a parameter so error counting works properly.

Also interesting that there are tens of thousands of errors with the same session ID, suggesting that some bots went crazy. That could be a consequence of the sessionstore outage, or maybe even the cause.

I don't think the login code has changed since 2015. Maybe it's due to the browser failing to log out of the bot session? Logout problems were mentioned above. (In which case, either the Selenium code does not check for logout success status, or the API gives it incorrectly; either way it's a bug, although one only triggered in unusual circumstances.)

But my tests never even try to log out… maybe something also changed in the test setups that causes the session cookie to survive when it used to be thrown away, or something. Anyways, fixed by checking if we’re already logged in.

  • beta sessionstore does not seem to report to logstash-beta

Possibly T233134? (Though you seem to have some data in that screenshot.)

Tgr added a comment.Tue, Oct 20, 1:17 AM

MediaWiki seems to log normally, it's the beta sessionstore service that has zero logs, despite apparently having had an outage.

But my tests never even try to log out… maybe something also changed in the test setups that causes the session cookie to survive when it used to be thrown away, or something. Anyways, fixed by checking if we’re already logged in.

I'm a bit confused about how those tests are supposed to work. Bot passwords only work for API requests, and presumably the browser test involves loading web pages? Are there two different kinds of logins? For the API, you can just use assert=user and catch assertion errors if you want to ensure you are logged in.

In any case, the error message you mention comes from action=clientlogin, not action=login (which is where bot passwords can be used), I think. So it seems like the browser is trying to do a normal login without terminating the bot login. I have no idea what has changed to trigger that.