Can't log in to mediawiki: canceled as a precaution against session hijacking?

Question

1. I'm using a private mediawiki hosted on AWS EC2 instance for years
2. I thought something gone wrong with some extension, specifically stopping in the middle of math rendering, so I tried to reload the page with Google Chrome browser's cache were all erased.
3. Right after that, I can't log in seeing this message "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."

I tried, 1. restart apache server 2. tried MediaWiki sessions and cookies not working on multi-server behind CloudFlare 3. tried Mediawiki, can't login after password change 4. tried "go in your LocalSettings.php and at the end add the following code of line :session_save_path("tmp");Create a folder "tmp" in your wiki installation directory. give rights 777 (permissions)" as in https://www.mediawiki.org/wiki/Topic:Pjby0sdeg3e60rfy 5. checked the server's hard disk storage, but it has free space of way more than 3.5gb.

How do I fix this and is there any way of disabling this really helpful "PRECAUTION" feature?

Germayne

First, that's almost certainly the wrong way to fix things. Second, consider that the message is unlikely to be telling you the whole truth. Something has gone wrong to the point that your session no longer makes sense. Hopefully you reverted the change at 4, because that only makes sense if the site never worked. You cleared your cache, but did you clear your cookies? Have you tried this in incognito mode? – Binominal

@Michael-sqlbot Yes, I reverted changes after unsuccessful tries, I tried in incognito mode and cleared every caches and cookies, even removed and reinstalled Chrome but still the problem persists. I was not even editing page - I was just viewing a page and cleared cache files noticing that the rendering was hanging in the middle of the page. – Germayne

Answer 1

Adding $wgSessionCacheType = CACHE_DB; to LocalSettings.php solves the problem. No need to change $wgMainCacheType.

This works, without the "precaution against session hijacking" error:

$wgMainCacheType = CACHE_ACCEL;
$wgSessionCacheType = CACHE_DB;

Volkslied

It worked. But somebody please explain why this work. What does this setting change and how does it solves it? – Coercion

Answer 2

Turned out to be something went wrong with cache settings in LocalSettings.php. Resolved after removing (almost all) customized cache settings.

Germayne

I had to change $wgMainCacheType = CACHE_ACCEL; to $wgMainCacheType = CACHE_NONE; – Equality

Answer 3

MediaWiki authentication and session handling has been rewritten for 1.27; see announcement (the last section). Session hijacking warnings mean the CSRF token you are submitting was not found in the session, which in turn usually means the session storage is configured wrong.

Dyadic

Okay, then I guess it was because of the session cache setting. Good to know that something has been changed for 1.27 and thanks for your answer! – Germayne

By the way, it's bit funny that mediawiki leaves no other ways of resolving the issue. Although I have a full control on my mediawiki installation and it's server, it doesn't make sense that it unconditionally rejects or cancels every actions I take and leaves my data totally inaccessible. At least, there must be some other methods for 'emergency' recovery. – Germayne

Your data is still available via direct DB access and maintenance scripts. CSRF is a serious security vulnerability and allowing CSRF prevention to be disabled is a bad idea. And it wouldn't help much since almost always the problem is that sessions do not persist over multiple requests. The first error triggered by that is the session hijacking one, but it's not like you canont login because of the anti-hijacking code. You cannot login because the server is unable the remember you (or anything). The error message could be improved -> T142434. – Dyadic

Answer 4

Twice now, we started getting this error after the server ran out of space. Turns out, both times it was because the objectcache table had been corrupted.

To fix it, just run the SQL statement (e.g. at a MySQL prompt):

REPAIR TABLE objectcache;

Marlyn

Unfortunately: "The storage engine for the table doesn't support repair" ... – Kwok

You could try backing up the database and running `DELETE FROM mw_objectcache;'. If the table name has any truth in it, its data isn't important. – Marlyn