Page MenuHomePhabricator

Session failure warning message ('sessionfailure') still gives bad advice
Open, Needs TriagePublic

Description

Happy 10 year old reunion, T19029.

As recently discussed on enwiki (https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=878410866#Cannot_log_on_through_TOR) the cryptic-to-end-users response in MediaWiki:Sessionfailure doesn't necessarily give useful advice. In recent testing it appears this message is generated for issues with authentication cookies, wherein "resubmitting the form" will never solve the problem. Suggest this is improved to at least mention that it can be generated due to cookie issues.

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

Xaosflux created this task.Jan 14 2019, 9:59 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 14 2019, 9:59 PM
Bawolff added a subscriber: Bawolff.EditedJan 15 2019, 4:25 PM

So looking at the code (I assume we are talking about login here):

protected static $messages = [ 
        'authform-newtoken' => 'nocookiesforlogin',
        'authform-notoken' => 'sessionfailure',
        'authform-wrongtoken' => 'sessionfailure',
];

In principle, you should only get the session failure error if your token doesn't match your cookie, or if the request was missing some fields. In the event you have cookies disabled you should get a different error message. (I have not tested this myself - perhaps this code is broken and giving the wrong error message)

Are we sure the user is reporting his situation correctly? He is also seems to be claiming that it used to work with cookies being blocked (Which is obviously not the case, since its impossible for any sort of login feature to work without cookies to maintain state). Although he implied that he was perhaps only blocking some cookies. I don't know for sure - but it seems reasonable that if only some login cookies are blocked, that mediawiki would throw up its hands in confusion and say that there is an unknown failure in the session management system

That said, probably couldn't hurt to mention cookies as a possibility in that error message.

In principle, you should only get the session failure error if your token doesn't match your cookie, or if the request was missing some fields. In the event you have cookies disabled you should get a different error message. (I have not tested this myself - perhaps this code is broken and giving the wrong error message)

That doesn't seem to be the case. I can't even figure out how to get the nocookiesforlogin message to display. Any attempt to log in (Firefox 64, Linux, any username or password) with all cookies blocked just gives me the same sessionfailure message as when I leave cookies enabled, but delete or mangle the token.

Change 487159 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[mediawiki/core@master] Fix nocookie warning on Special:Userlogin

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

So i figured out the cause.

The no cookie detection code is fragile and only works the first time ->getToken() is called. This is icky and other code had side effects that prevented it from working.

I gave a fix above, but that's kind of hacky. At the very least it should have tests. But it looks complex to add tests for this behaviour, and I don't really have the time at the moment to fix this properly, so I'm not sure that patch will be accepted. So Umm, if anyone wants to fix this properly that'd be great (sorry for the cop-out).