Topic on Project:Support desk/Flow

Cookie problem, $wgCookieSecure enabled but site is not https

I have just set up MediaWiki (1.29.0) on an AS400 IBM i machine. Though I can navigate the site, as well as create/edit pages, I cannot log in or create a new account. Every attempt to do so gives me "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 have tried adding "session_save_path("tmp");" to LocalSettings.php, as well as play with values of $wgMainCacheType and $wgSessionCacheType with no luck. Currently, my shared memory settings in LocalSettings.php have only these two lines:

$wgMainCacheType = CACHE_ACCEL;

$wgMemCachedServers = [];

How can I fix this? I believe my CSRF token is not being correctly cached in my session, but I'm not sure how to correct it.

I am using MariaDB as a database, Apache for the server, and PHP 5.5.37.

If you have $wgMainCacheType = CACHE_ACCEL; you should provide a persistent data storage in $wgSessionCacheType

I have $wgSessionCacheType = CACHE_DB;

I've been able to look into my objectcache table, and found that MWSession is being stored correctly, (as in it's the same value as <my-wiki>_session in the response header's cookie). Is there another location where that value is written/read? I figure since I know it's being cached, but my comparison is still failing, that the fault is probably in getting/setting whatever value the cached token checks against, right?

Also, for what it's worth, I've since tried installing MediaWiki using version 1.27.3, but I'm still facing the same problem.

Another update: I've been fiddling with the source code to see if I can narrow down where my problem is occurring. This is what I'e found:

AuthManagerSpecialPage::trySubmit() is where the token mismatch is caught. $requestTokenValue and $sessionToken are not the same

setting $secret in Token::__construct to some constant allows me to sidestep the "hijacking" error, but in it's place is the error "Cookies may be disabled. Ensure you have cookies enabled start again" (my cookies are enabled), as well as the warning "You are already logged in as <username>. Use the form below to log in as another user" ("log in" changes to "sign out", but navigating away from the page at all signs me out). Supplying an incorrect password or username yields the appropriate error there, so WikiMedia is correctly able to check my credentials.

Obviously, making $secret a constant wasn't going to solve my problem, but hopefully faking it through the first error can shed some more light on what's actually going wrong.

Be sure that session.referer_check is set to Off in php.ini, this can cause such invalid session problems.

setting a debug log may give some details.

I have set session.referer_check to Off (it wasn't set before), but there is no change in behavior.

If it helps, here are several logs and headers:

Here is my session log file:

2017-08-23 16:56:05 <server> <wikiname>:  // each line starts with this. Removed for readability.
SessionBackend "vtke98qe2fq7n3uov79nlef7lq5g7s55" is unsaved, marking dirty in constructor
SessionBackend "vtke98qe2fq7n3uov79nlef7lq5g7s55" save: dataDirty=1 metaDirty=1 forcePersist=0
SessionBackend "vtke98qe2fq7n3uov79nlef7lq5g7s55" force-persist due to persist()SessionBackend "vtke98qe2fq7n3uov79nlef7lq5g7s55" save: dataDirty=0 metaDirty=1 forcePersist=1
SessionBackend "vtke98qe2fq7n3uov79nlef7lq5g7s55" Taking over PHP session
SessionBackend "vtke98qe2fq7n3uov79nlef7lq5g7s55" save: dataDirty=0 metaDirty=1 forcePersist=1
SessionBackend "vtke98qe2fq7n3uov79nlef7lq5g7s55" data dirty due to dirty(): LoginSignupSpecialPage->getFakeTemplate/SpecialUserLogin->getToken/MediaWiki\Session\Session->getToken/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty
SessionBackend "vtke98qe2fq7n3uov79nlef7lq5g7s55" save: dataDirty=1 metaDirty=0 forcePersist=0

cache log file:

2017-08-23 16:55:59 <server> <wikiname>: //Same as above
cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff, session: SqlBagOStuff
LocalisationCache: using store LCStoreDB
cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff, session: SqlBagOStuff
LocalisationCache: using store LCStoreDB
cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff, session: SqlBagOStuff
LocalisationCache: using store LCStoreDB
cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff, session: SqlBagOStuff
LocalisationCache: using store LCStoreDB
cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff, session: SqlBagOStuff
LocalisationCache: using store LCStoreDB
cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff, session: SqlBagOStuff
LocalisationCache: using store LCStoreDB
cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff, session: SqlBagOStuff
LocalisationCache: using store LCStoreDB

Request header:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Host:<server>
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

Response header:

Cache-Control:private, must-revalidate, max-age=0
Connection:close
Content-language:en
Content-Type:text/html; charset=UTF-8
Date:Wed, 23 Aug 2017 16:56:04 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Server:Apache
Set-Cookie:ZDEDebuggerPresent=php,phtml,php3; path=/
Set-Cookie:<wikiname>_session=vtke98qe2fq7n3uov79nlef7lq5g7s55; 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

The logs look good, it uses the same cookie vtke98qe2fq7n3uov79nlef7lq5g7s55. Would be interesting to see what happens when the browser sends back the same cookie to MediaWiki, if MediaWiki is replacing it with a different one.

I've finally found the issue to my problem (I'm 12.197.215.194 by the way). By default, MediaWiki passes the <wikiname>_sessioncookie with the secure flag set, but my webserver can only host http, 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.

Adding $wgCookieSecure = false; to the bottom of my localSettings.php file solved the problem.

I realize now that none of my logs/headers included the fact I was using http, so it was pretty much impossible for a third party to tell that could have been an issue. If a future user has a similar problem, it might be worth confirming which protocol they're using.

Thanks for all your help!

Thank you for posting your resolution!