In MediaWiki 1.27 sessions are no longer stored using the default php session storage, but on the object cache. If you've changed $wgMainCacheType, you may need to tune $wgSessionCacheType, in case the caching you've chosen is not persisting data across requests. Setting $wgSessionCacheType = CACHE_DB; would be a sensible value.
Hello,
after an upgrade from 1.26.3 to 1.27 nearly all works fine including special pages and creating or editing pages. But when I try to login (and as an Administrator I must login for some tasks), I get the following message "There seems to be a problem with your login session; this action has been canceled ... ". The same happens, when I want to create an account. There are no extensions for account control/rights management installed.
What can or have I to do.
Many thanks .
Try creating a directory: tmp, in the MediaWiki installation directory and include the following line in your LocalSettings.php, at the end:
session_save_path("tmp");I didi it. I've set the appropriate permissions to that folder. I reloaded the main page and tried to login. Same error. The "tmp" folder remains empty.
Creating a tmp folder on the mediawiki installation for storing sessions is a high security risk, since that folder is probably accessible from the web and anyone could potentially see the active sessions on the server. If sessions were working before the upgrade, the session save path shouldn't be the problem.
Try to set up a debug log file and repeat the action of logging in, and see if there's something in the log that can give more information about what's going one (in case you want to post the log output here, remove any private information like the login credentials, as the manual describes)
Yeah, sorry about the high risk solution, but I was having the same problems and had the tmp folder temporarily (for about a couple of minutes) set-up which apparently fixed any session lost issues. Another mistake I was making was jumping from HTTP to HTTPS and vice versa (maybe that's your problem too).
Again, apologies for the high risk solution.
I agree with Ciencia. It seems to be a problem with the new session handling in 1.27. In 1.26.x I've never lost my sessions. It seems so, that my sessionID changes every time when I send a request to the server (I don't switch between http and https). But I don't have a reason and not a solution. So I post the error.log here.
Start request POST /wiki/index.php?title=Spezial:Anmelden&returnto=Hauptseite
HTTP HEADERS:
HOST: MyServer.de
USER-AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
ACCEPT-LANGUAGE: de,en-US;q=0.7,en;q=0.3
ACCEPT-ENCODING: gzip, deflate
DNT: 1
REFERER: http://MyServer.de/wiki/index.php?title=Spezial:Anmelden&returnto=Hauptseite
COOKIE: __utma=160677477.911326897.1398857347.1467369865.1467636887.185; __utmz=160677477.1422875023.52.3.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); my_wikiUserName=MyUserName; __utmc=160677477; MyGitWikiSession=ge9bns6c6h48et2s4rrjs3v45h9psflf; my_wikilanguage=en; uls-previous-language-autonym=English; mw_installer_session=sh49d0t4af333d2jrb39n8ni37; IPBWikiSession=nifd5814p6ns4l022hnlllm4v0; ipb_wikiUserID=1; ipb_wikiUserName=MyUserName; ipb_wikiToken=f3eb3f4043d61703fec60a996fb7d0b0
CONNECTION: keep-alive
PRAGMA: no-cache
CACHE-CONTROL: no-cache
CONTENT-TYPE: application/x-www-form-urlencoded
CONTENT-LENGTH: 185
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[session] Session "ge9bns6c6h48et2s4rrjs3v45h9psflf" requested without UserID cookie
[session] SessionBackend "ge9bns6c6h48et2s4rrjs3v45h9psflf" is unsaved, marking dirty in constructor
MWCryptRand::realGenerate: Generating cryptographic random bytes for MediaWiki\Session\SessionManager->generateSessionId/MWCryptRand::generateHex/MWCryptRand->realGenerateHex/MWCryptRand::generate/MWCryptRand->realGenerate
MWCryptRand::realGenerate: openssl_random_pseudo_bytes generated 20 bytes of strong randomness.
MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer.
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" metadata dirty due to ID reset (formerly "ge9bns6c6h48et2s4rrjs3v45h9psflf")
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" save: dataDirty=1 metaDirty=1 forcePersist=0
[cookie] setcookie: "MyGitWikiSession", "n94eau9g0hoeo1397jtdsf281grae587", "0", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiUserID", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiToken", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "forceHTTPS", "", "1436186784", "/", "", "", "1"
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" save: dataDirty=1 metaDirty=1 forcePersist=0
[cookie] already set setcookie: "MyGitWikiSession", "n94eau9g0hoeo1397jtdsf281grae587", "0", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiUserID", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiToken", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "forceHTTPS", "", "1436186784", "/", "", "", "1"
[cookie] already set setcookie: "MyGitWikiSession", "n94eau9g0hoeo1397jtdsf281grae587", "0", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiUserID", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiToken", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "forceHTTPS", "", "1436186784", "/", "", "", "1"
IP: 192.124.243.164
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" Taking over PHP session
Fully initialised
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[MessageCache] MessageCache::load: Loading en... local cache is empty, got from global cache
Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache->getParser
Parser: using preprocessor: Preprocessor_DOM
Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions->__construct
QuickTemplate::__construct was called with no Config instance passed to it
MWCryptRand::realGenerate: Generating cryptographic random bytes for PasswordFactory::generateRandomPasswordString/MWCryptRand::generateHex/MWCryptRand->realGenerateHex/MWCryptRand::generate/MWCryptRand->realGenerate
MWCryptRand::realGenerate: openssl_random_pseudo_bytes generated 7 bytes of strong randomness.
MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer.
MWCryptRand::realGenerate: Generating cryptographic random bytes for MediaWiki\Session\Session->getToken/MWCryptRand::generateHex/MWCryptRand->realGenerateHex/MWCryptRand::generate/MWCryptRand->realGenerate
MWCryptRand::realGenerate: openssl_random_pseudo_bytes generated 16 bytes of strong randomness.
MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer.
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" data dirty due to dirty(): LoginSignupSpecialPage->getFakeTemplate/SpecialUserLogin->getToken/MediaWiki\Session\Session->getToken/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" save: dataDirty=1 metaDirty=0 forcePersist=0
User::getBlockedStatus: checking...
[connect] Connected to database 0 at localhost
MediaWiki::preOutputCommit: all transactions committed
MediaWiki::preOutputCommit: pre-send deferred updates completed
OutputPage::sendCacheControl: private caching; **
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
Request ended normally
[session] Saving all sessions on shutdown
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[connect] Connected to database 0 at localhost
[connect] Connected to database 0 at localhost
[MessageCache] MessageCache::load: Loading en... local cache is empty, got from global cache
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[connect] Connected to database 0 at localhost
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[connect] Connected to database 0 at localhost
[connect] Connected to database 0 at localhost
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[connect] Connected to database 0 at localhost
I got the same problem as 192.124.243.164, but I only started to experience this problem in Mediawiki 1.27 after I updated to PHP 7.
It's strange to see like two different cookie prefixes:
Do you have a clue about where does both come from? Do you have 2 wikis on the same domain/subdomain? If in doubt, try clearing cookies or navigate using private browsing to be sure there aren't leftover cookies from older installations.
Anyway, I've mentioned this thread on task T138072 that seemed related, although that one seems to happen on WMF wikis.
Well I don't know about user 192.124.243.164, but for me it seems that PHP 7 is causing the issue because I have uninstalled PHP 7 and installed PHP 5 back and enabled it and now everything seems to be working again. Does anyone know why would PHP 7 cause such problems and how could I fix it so I can use it again?
On task T138072 some devs request if someone can post HTTP headers of the request and response of the first access to the login form and when logging in.
To get HTTP request and response headers, open the developer tools of the browser (hit F12). There should be a network tab, click on it. It's a good idea to start a private browser session before loading the page, so you don't have cookies of previous sessions.
Go to the login page, the network tab should list each request to the server: select the first item, which should be the login URL. At the right there should be some other panels with information about the selected URL, click on the "headers" panel. In Firefox, click the "unmodified headers" (or similar) button to display them in a format you can copy and paste. In chrome, click the "view source" link in request and response headers.
Do the same for when you submit the user & password (user and password are sent in a POST request, so they won't appear in HTTP headers, but check for them anyway just in case)
You can paste them on https://phabricator.wikimedia.org/paste/edit/form/14/ and if you're concerned about possible privacy issues, you can change visibility to "subscribers" and add manually trusted devs like Anomie to the subscribers list.
Another cause may be an extension, you can try disabling all extensions and see if the problem is still happening.
Okay, so I was wrong about it only not working in PHP 7, I still have the problem with PHP 5 as well. I am not able to use my accounts even if I go into private browsing. I even tried out an other pc on an entirely different network and it doesn't work there either.
I have created a paste form on phabricator based on your instructions Ciencia. Is this how am I supposed to do it: https://phabricator.wikimedia.org/P3340 Is there any more I need to do?
The wiki I work at switched to 1.27 and is now experiencing login problems as well, but also we can't even edit anything. Not sure if that's related but it probably is sinice it started happening at the same time.
Thanks for the headers, Tribly! Hopefully this is enough to diagnose the problem.
Hi, I'm 192.124.243.164 (registered now to the Support_desk).
I had not much time today but investigated a little what happens with cookies and session data. The old 1.26 Wiki sets a cookie, when navigating to the login page and two more after login. Because there is not set a session.save_path in the php.ini the session data are saved in the systems temp-dir (/var/lib/php5 on my machine). Works fine. After deleting all cookis and all session data I tried out the new wiki, which runs on the same machine, installed in a separate directory with a separate database and different session name.
The new 1.27 wiki also sets a cookie when navigating to the login page but this cookie changes its value after every new request. I couldn't find session data anywhere on the machine. So I think, that the new wiki (or its session engine) is unable to save the session data and that's the reason. Does anybody know, where the 1.27 engine tries to save the session data or how to configure it? Setting a session.save_path has no effect (and yes, I've restarted apache and the path was readable and writable for apache and php).
Many Thanks
In 1.27 it saves session data to the cache specified with $wgSessionCacheType.
Alright, so I tried to switch back to the 1.26 version of mediawiki(I made a backup folder before updating to 1.27, so I only had to rename that folder to html to switch back, and rename the 1.27 folder to something else.) and when I tried to login I got the following error Wiki uses cookies to log in users. You have cookies disabled. Please enable them and try again.. I tried to login with other accounts as well and tried other browsers as well but every time I got the same error. So I googled the error and got this post: https://www.mediawiki.org/wiki/Topic:Rg3w5u0e70fs8l4e
The solution to the post was:
The session cookie are not working when session.referer_check = On is set in php.ini. Maybe there sould be iniset in php.ini or at least a check for this setting
So I go into my php.ini file and searched for session.referer_check and find that there was no value set for session.referer_check and it was like this: session.referer_check =
So I set session.referer_check to Off: session.referer_check = Off
Then I restarted apache with sudo service apache2 restart and after that I was able to login again with every account. I switched back to 1.27 and it seems to be working there as well.
Also wanted to try out my wiki with this method with PHP7 but it was not working. Seting the session.referer_check to Off in the PHP7's php.ini had no effect. So I set back pnp.ini to it's default state(session.referer_check =) then I looked through my php extensions and I notified that apcu was missing for PHP7. I installed it and now it seems to be working with PHP7 without even the need to modify the php.ini. I also tried to login in private browsing and it worked. My fellow staff members have also tried to login and it's working for them.
For PHP5 I have the following extensions installed:
apcu.ini curl.ini gd.ini imagick.ini intl.ini json.ini mcrypt.ini mysql.ini mysqli.ini opcache.ini pdo.ini pdo_mysql.ini readline.ini xcache.ini
And For PHP7 I have the following extensions installed:
apcu.ini apcu_bc.ini calendar.ini ctype.ini dom.ini exif.ini fileinfo.ini ftp.ini gettext.ini iconv.ini json.ini mbstring.ini mysqli.ini mysqlnd.ini opcache.ini pdo.ini pdo_mysql.ini phar.ini posix.ini readline.ini shmop.ini simplexml.ini sockets.ini sysvmsg.ini sysvsem.ini sysvshm.ini tokenizer.ini wddx.ini xml.ini xmlreader.ini xmlwriter.ini xsl.ini
Hello again,
regarding Anomies tip I've learned, that MW 1.27 stores the sessions always in object cache (so in Memory?) and $wgSessionCacheType has the same possible values as $wgMainCacheType. Hmmm. I have installed APCu. My $wgSessionCacheType was not set but $wgMainCacheType = CACHE_ACCEL (using $wgSessionCacheType instead of or in combination with $wgMainCacheType has no effect). When I set $wgMainCacheType to any other of the possible values, Problems have gone (login works). So far so good. I use now CACHE_ANYTHING until I understand a little bit more about the underlying mechanisms.
I'm a little bit confused about some things.
Whe I use $wgMainCacheType = NONE; isn't it so, that no object caching is used and if so, where are the session data stored? Loggin works.
I've read, that APC (APCu) does not work with PHP5 because PHP5 uses OPcache which is bundled with PHP 5.5 and later (I have PHP 5.5.9 installed). Nevertheless, I have installed APCu and I didn't have any problems with MW 1.26 and prior.
Regarding Triblys experience with session.referer_check I can only say, that this variable in my php.ini has not a value and that seems to be ok because I don't want to make a pattern check to the referrer string.
Hope the tip with $wgMainCacheType helps anybody.
Regards Mosi.
Yes, setting $wgMainCacheType = NONE; seems to be the solution here. I wonder why it hasn't been set up this way in DefaultSettings.php
Sorry for the confusion, I meant $wgSessionCacheType which the documentation doesn't make clear where sessions would be stored depending on the value of $wgMainCacheType. As the manual page is now, it seems like $wgMainCacheType = NONE would make $wgSessionCacheType = NONE as well
Thank you all for your effort. You helped me really. I've upgraded the second Wiki (which is the "real" wiki, the other is for testing e.g. if upgrades make problems). Same problem, same solution. I'm in vacation the next days but I've a lot of suggestions for expanding my knowledge about configuring and maintainig a wiki.
I have found that setting the wiki to "read-only" mode ($wgReadOnly) makes the problem significantly worse. I set "$wgMainCacheType = CACHE_DB;" as suggested, and am crossing my fingers that it gets fixed before it causes any serious problems.
After changing $wgMainCacheType to CACHE_ANYTHING, CACHE_NONE, CACHE_DB and CACHE_ACCEL, there was no change in the symptoms. Still having the same error.
I had the same issue after updating my server to Ubuntu 16.04.1, PHP to 7.x and MediaWiki to 1.27.1 and could no longer log in. I then changed my $wgMainCacheType from CACHE_ACCEL to CACHE_DB, saved my changed LocalSettings.php, reset Apache2 and can now successfully log in again.
I'm using MediaWiki 1.27.1 with PHP 7.0.8 and I have to set $wgMainCacheType to CACHE_NONE; or I will get logged out as soon as I visit another page on my wiki :/ I'd love to use OPcache though, so what can I do? Thanks and cheers!
Just make sure $wgSessionCacheType is set to a cache that is persistent and (if you have more than one server) shared, then you can set $wgMainCacheType to whatever you want.
Thank you, Anomie! It's weird, somehow the following combination kinda works now:
$wgMainCacheType = CACHE_ACCEL; $wgParserCacheType = CACHE_ACCEL; $wgMessageCacheType = CACHE_ACCEL; $wgSessionCacheType = CACHE_DB;
However, I have to log in twice: when I log in, it shows that I'm logged in but when I go to another article or just click edit, I'm suddenly logged out. I have to log in again and this time it is persistent and I can edit articles. As soon as I log out, everything starts all over again.
Do I have to change $wgAuthenticationTokenVersion? Right now it's set to $wgAuthenticationTokenVersion = "1"; And I'm also using CentralAuth:
$wgCentralAuthCookies = true; $wgCentralAuthCookieDomain = '.domain.com';
Thanks and cheers!
Sorry, I don't know what happened but everything works perfectly now. Thanks and cheers!
@Anomie Should've never this https://github.com/wikimedia/mediawiki/blob/d175b391ae2a77e3183b2608bb4422782af092a1/includes/Setup.php#L701 be updated to use the DB?
Had the same problem after an upgrade. Adding
$wgSessionCacheType = CACHE_DB;
in LocalSettings.php as described above helped - thank you very much!
setting
$wgSessionCacheType = CACHE_DB;
worked for 1.28, saved my day, thanks!
Had same problem: Hint with creating tmp-folder and adding session_save_path("tmp"); at the end in localsettings.php helped. thank you!
^In which case you should also be aware of the security risk mentioned in the second comment after the "session_save_path("tmp")" one.
For my case, adding the "tmp" line (for whatever reason) also resolved the issue. Additionally, I soon removed this line which (again for whatever reason) didn't bring back the "loss of session data" issue.
I cannot log in after my 1.28 upgrade. I'm on a hosted server. I have this in LocalSettings.php:
## Shared memory settings $wgMainCacheType = CACHE_NONE; $wgMemCachedServers = array(); $wgSessionCacheType = CACHE_DB;
It distinguishes correct and incorrect passwords just fine (errors on incorrect ones), but after logging in, I go back to the page I came from and still see "Log in."
Any other things I may be doing wrong? This was an upgrade from 1.26.
Can you try from a private browsing tab of your browser (which should be identical to clear the cookies)?
I found the problem. I was hitting the site with http. When forced to https, all became fine. Doh!
Hi guys,
I just installed a 1.28 with MS SQL database. I tried everything above, still cannot login or create new account.
Any new ideas?
Richard
Thanks, this fix worked on a Synology DS216j
/usr/syno/bin/synopkg version MediaWiki 1.28.2-0125 nano /volume1/web/MediaWiki/LocalSettings.php $wgSessionCacheType = CACHE_DB; sudo /usr/syno/bin/synopkg restart MediaWiki Password: package MediaWiki restart successfully