I have just set up a MediaWiki 1.29.0 page on an AS400 IBM i machine. I am using MariaDB as a database. I am using PHP 5.5.37
Every time I try to log into an account, I get the error:
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.
Obviously, the behavior I’m looking for is to log in.
I’ve tried:
- changing
$wgMainCacheType
and$wgSessionCacheType
to various permutations ofCACHE_NONE
,CACHE_ACCEL
,CACHE_DB
, andCACHE_ANYTHING
. - creating a tmp directory and setting its permissions.
- rebuilding my
LocalSettings.php
file. - setting
session.referer_check=off
in php.ini
I’ve checked and I know my cookies are enabled (I’m able to call document.cookie;
and get data back).
This question has been asked before here, and the linked questions within, but no solutions fixed my problem. They also deal with an older version of WikiMedia, though I don’t know if that makes a difference in this instance.
EDIT: I am also getting the same behavior when I try to create a new account. However, I am able to navigate the wiki, create pages, and edit pages without any sort of error.
Here is my request header:
Cache-Control: private, must-revalidate, max-age=0 Connection: close Content-language: en Content-Type: text/html; charset=UTF-8 Date: Thu, 10 Aug 2017 13:48:36 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT Link: </<path>/resources/assets/logo.png?88d75>;rel=preload;as=image Server: Apache Set-Cookie: ZDEDebuggerPresent=php,phtml,php3; path=/ Set-Cookie: <wikiname>_session=n7gs0ct99ck5i2juq0togto9q7bfou6u; path=/; secure; httponly Transfer-Encoding: chunked Vary: Accept-Encoding,Cookie X-Content-Type-Options: nosniff X-Frame-Options: DENY X-Powered-By: PHP/5.5.37 ZendServer/8.5.5 X-UA-Compatible: IE=Edge
Here is my response header:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Accept-Encoding:gzip, deflate Accept-Language:en-US,en;q=0.8 Connection:keep-alive Cookie:ZDEDebuggerPresent=php,phtml,php3 Host:tdidev:10080 Referer:http://<wikiepath>/index.php?title=Special:UserLogin&retirnto=Main+Page Upgrade-Insecure-Requests:1 User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36
Advertisement
Answer
I’ve finally found the issue to my problem. By default, MediaWiki passes the <wikiname>_session
cookie with the secure flag set. Taken from OWASP:
The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text.
To accomplish this goal, browsers which support the secure flag will only send cookies with the secure flag when the request is going to a HTTPS page. Said in another way, the browser will not send a cookie with the secure flag set over an unencrypted HTTP request.
So my MediaWiki installation correctly creates and caches a session token, and it even still passes it through the response header. However, since my browser sees an http
instead of https
, that’s as far as the token gets. The Set-Cookie
line is simply ignored.
There is a setting in php.ini called session.cookie_secure
, but MediaWiki ignores this flag.
Instead, the solution was to add this line to the bottom of my localSettings.php
file:
$wgCookieSecure = false;