[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Page MenuHomePhabricator

Logging in to a wiki sometimes fails with 'sessionfailure' error (coinciding with SameSite rollout)
Closed, DeclinedPublic

Description

If you experience this, please post the name and version of your browser, whether you have used the desktop or mobile site, whether you have checked the "keep me logged in" option, a screenshot of https://samesite-sandbox.glitch.me/ and the name and the first 4-5 characters of the value for all the cookies with "session" or "token" in their name (but no more than that, the full string would give others access to your account!). (see how) Also, if you remember what exact navigation steps led you to that error screen, that would be helpful.

On login, some people get the sessionfailure message:

image.png (177×309 px, 9 KB)

Like T257853: CentralAuth edge login broken on desktop (coinciding with SameSite rollout), it seems to be related to the presence of old cookies somehow. Going incognito or clearing cookies helps.

Event Timeline

Tgr subscribed.

Could you provide more details of what you are doing and what happens?

Also, could you share a screenshot of what you see here?

I'm in Special:UserLogin, I put my password and press Log In, but when I press Log In it doesn't respond and shows the message in MediaWiki:Sessionfailure. Here's the screenshot of the SameSite thing.

Requested screenshot bug report.png (488×921 px, 41 KB)

What browser and OS are you using? Any special settings (third-party cookie blocking, some privacy extension)?

My OS is Windows 7 my browser is Google Chrome. I don't have any cookie blocking or privacy extension.

Tgr renamed this task from Wikipedia log in problem to Logging in on Wikipedia fails with 'sessionfailure' error.Jul 16 2020, 1:35 AM

You are using the desktop site, right? Can you do another login attempt and provide the exact time when you did it? Can you retry in incognito mode (with "Block third-party cookies" disabled)? If you have an alternative account, can you retry with that?

Yes, I'm with the desktop site. I tried with my alternative account SRuizR777 in incognito mode at 1:50 UTC. Surprisingly it worked. I tried with my main account SRuizR in incognito mode at 1:52 UTC and it also worked.

At 1:55 UTC I tried out of incognito and it didn't work.

Nevermind, I restarted my computer and now it's working. Kind regards.

Thanks! Please reopen if you see this again; we made some changes to the login system, in response of a change in browser behavior (which is rolled out this week and next) so we are very interested in reports of errors (although I'd mostly expect them to happen around cross-wiki login, not direct login).

Tgr reopened this task as Open.EditedJul 16 2020, 4:59 PM

Reopening, happened to another person so clearly not a fluke. Seems to be related to the presence of old cookies. (Maybe the SameSite=None and the legacy cookie getting out of sync?) If you experience this, please post the name and version of your browser, a screenshot of https://samesite-sandbox.glitch.me/ and the first 4-5 characters of all the cookies with "session" or "token" in their name (but no more than that, the full string would give others access to your account!). Also, if you remember what exact navigation steps led you to that error screen, that would be helpful.

T257853: CentralAuth edge login broken on desktop (coinciding with SameSite rollout) seems also related to the presence of old cookies somehow.

Tgr renamed this task from Logging in on Wikipedia fails with 'sessionfailure' error to Logging in to a wiki sometimes fails with 'sessionfailure' error.Jul 16 2020, 5:08 PM
Tgr updated the task description. (Show Details)
This comment was removed by alaa.

name and version of your browser, whether you have used the desktop or mobile site

Desktop - Google chrome 83.0.4103.116

checked the "keep me logged in" option

No

a screenshot of https://samesite-sandbox.glitch.me/ and the name and the first 4-5 characters of the value for all the cookies with "session" or "token" in their name

Maybe it'll not help you now? as I faced it on 2:11 p.m. today. I can't log in through arwiki and enwiki, then I tried through metawiki, so I can log in through metawiki only, and when enter arwiki/enwiki the unified login not work, and I'd log in again through each project alone. So I asked through IRC, and directed me to T258148. I read on it I cleared the cookied for wikipedia.org and was able to login again, so I cleared cookies then restarted the browser. Then all back work fine!

Tgr renamed this task from Logging in to a wiki sometimes fails with 'sessionfailure' error to Logging in to a wiki sometimes fails with 'sessionfailure' error (coinciding with SameSite rollout).Jul 17 2020, 10:39 AM

@Aklapper I finally managed to log in, in practise it was my not-updated browser; the current version is 12.1.1.36. Thank you for your time.

I found steps to reproduce this on Firefox 106.0.5 (Release):

  1. At about:config, set javascript.enabled to false
  2. Log in at https://en.wikipedia.org/wiki/Special:UserLogin
  3. Load https://commons.wikimedia.org/wiki/Special:UserLogin

Autologin never happens, and attempts to log in through the form cause sessionfailure. The Special:CentralAutoLogin GETs (checkLoggedIn, createSession, validateSession and setCookies) all occur as they do with JavaScript on.

matmarex subscribed.

There's nothing we can do today about this bug from 3 years ago now. Any logs we had have long since been deleted, and any faulty cookies would have expired after at most a year.

But we understand these kinds of issues better these days (problems which are caused by cookies being set with identical names but different parameters), and if you run into anything like that today, please file a task, and we'll try to do better this time – on the MediaWiki-Platform-Team we have been working on login issues recently and we would like to investigate any new problems.


@RAN1 Your problem was probably something different. If you still see that, please file a task, and we'll look into it.