Topic on Project:Support desk/Flow

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

Hi!

So I've been running a MediaWiki site for a year or so. Everything was running smoothly last time i checked, but when I tried to login today I received the following error:

"Wiki uses cookies to log in users. You have cookies disabled. Please enable them and try again."

Cookies are not disabled in my browser (tested with Chrome and IE).. I haven't made any changes to my WikiMedia lately so I'm not sure why I'm getting this message now.

Facts:

Version:

MediaWiki 1.19

PHP 5.3.27

Database: MySQL 5.1.49

Have anyone experienced this issue? It kinda sucks to not be able to login to own wiki as I have a lot of information there I do not wish to loose.. It doesn't seem like a commen issue. I have been googling for solutions, but haven't found anything yet. I've also tried:

http://stackoverflow.com/questions/16127882/how-can-i-fix-the-mediawiki-error-wiki-uses-cookies-to-log-in-users-you-have-c <- didn't work

Also: sorry for this duplicate post, but I could not update the content of my first post, only the subject..

Thanks in advance

Hm, i really thought this was the #1 place to get help :S

did you see my reply?

Since this seems to be related to session storage, what does you phpinfo say is the session directory? (Here is how to get the phpinfo information.)

Hi Mark,

Thanks for your reply. I have been looking into the session stuff as well before I posted here. Please see link for PHP session paramters.

So, what are the permissions on /tmp?

drwxrwxrwt 8 root root 1.4K Sep 20 23:43 tmp

Ugh...

Can you turn on the debug log? It should show the request headers. Could you verify that the cookie headers are being sent?

Look through the rest of the debug log file, maybe sanitize it and post it to pastebin, and see if you see any problems there.

Trying to think of some more things to try...

Sure thing. Debug is enabled. Tried to login one more. Output is below. Hope this makes more sense to you than it does to me :)

Start request

POST /MediaWiki/index.php?title=Spesial:Logg_inn&action=submitlogin&type=login
HTTP HEADERS:
HOST: randomhost
CONNECTION: keep-alive
CONTENT-LENGTH: 109
CACHE-CONTROL: max-age=0
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
ORIGIN: http://randomhost
USER-AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36
CONTENT-TYPE: application/x-www-form-urlencoded
REFERER: http://randomhost/MediaWiki/index.php?title=Spesial:Logg_inn&action=submitlogin&type=login
ACCEPT-ENCODING: gzip,deflate,sdch
ACCEPT-LANGUAGE: en-US,en;q=0.8
COOKIE: stay_login=0; id=8WkM3tsRm8iDY

CACHES: EmptyBagOStuff[main] SqlBagOStuff[message] SqlBagOStuff[parser]
Class LanguageNb not found; skipped loading
LocalisationCache: using store LCStore_DB
Connecting to localhost my_wiki...
Profiler::instance called without $wgProfiler['class'] set, falling back to ProfilerStub for safety
Connected to localhost my_wiki.
Fully initialised
session_set_cookie_params: "0", "/", "", "1", "1"
wfFixSessionID: PHP's built in entropy is disabled or not sufficient, overriding session id generation using our cryptrand source.
MWCryptRand::realGenerate: Generating cryptographic random bytes for wfFixSessionID/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.
Unstubbing $wgAuth on call of $wgAuth::validDomain from LoginForm::load
Connecting to localhost my_wiki...
IP: 10.0.0.20
Connected to localhost my_wiki.
MessageCache::load: Loading nb... 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
MWCryptRand::realGenerate: Generating cryptographic random bytes for LoginForm::setLoginToken/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.
Class SkinVector not found; skipped loading
Class PEAR_Error not found; skipped loading
DatabaseBase::query: Writes done: REPLACE INTO `msg_resource` (mr_resource,mr_lang,mr_blob,mr_timestamp) VALUES ('user.options','nb','{}','20130920222847')
OutputPage::sendCacheControl: private caching;  **
Request ended normally

I'm just looking at this right now, but the things I'm looking for are session-related, of course. I'm wondering about the following lines:

wfFixSessionID: PHP's built in entropy is disabled or not sufficient, overriding session id generation using our cryptrand source.

but you didn't say PHP was upgraded, so this probably isn't the cause.

I assume that you're seeing the "Wiki uses cookies..." right after this request, right?

I'm disappointed that there were better messages. If I give you a patch, can you apply it so we get some better messages?

Hi,

I tried to login today, and now it works :S. Makes no sense, but i'm going to export my wiki just in case.

Thanks for letting me know. In the meantime, I found a couple of things that may help troubleshoot this if I see it again. That, and I'm going to get some better messages added to the debug log.

Hmm, seems that Wikimedia didn't like my formatting. / didn't do the trick so I just took syntaxhighlight.. Didn't expect to get the "invalid language" box as well :S Please let me know if I should upload a file with the output to my dropbox.

I edited it. For these sorts of things, <pre> is best.

Has there been any recent updates on solving this? It happened to me before shortly after installing the wiki and so i simply started over but now it has happened again, so i will need to find out the issue and deal with it properly. It has been like this for a week now so i dont think it will go away itself like with the original poster. Note: I am an application developer but i dont know a thing about websites so it could be a very basic mistake i am making. I have tried cleaning my tmp folder at the webstie route and i have made sure the php.ini says session.save_path = "/tmp"; as directed by the link: http://stackoverflow.com/questions/1148583/problem-with-mediawiki-cookies/14067411#14067411 I also created a /tmp folder in the wiki folder. Any help would be greatly appreciated.

For me, deleting existing sessions (rm -v /tmp/sess_*) fixed the cookie/log-in issue. Very weird.

I have the same problem tryed all of the above but still cannot login any more :

any sugestions :

Start request POST /wiki/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page
HTTP HEADERS:
CONTENT-LENGTH: 100
CONTENT-TYPE: application/x-www-form-urlencoded
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
ACCEPT-ENCODING: gzip, deflate
ACCEPT-LANGUAGE: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4
CACHE-CONTROL: max-age=0
CONNECTION: keep-alive
COOKIE: wiki_wiki__session=Xey8ruUjT37RkHTyxBSSjx44RJ7BjPTKHeamAP6LBL3LpnDhXhh8OTM5Wq8p8sFi; wiki_wiki__session=iRjV8yFo0IyUovl16xefXbd_KwT3wgFCRC3b1YylJD5wvV0MHdPQHsW8eebXjPgd
HOST: some.site.nl
ORIGIN: https://some.site.nl
REFERER: https://some.site.nl/wiki/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page
USER-AGENT: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
[caches] main: MemcachedPhpBagOStuff, message: MemcachedPhpBagOStuff, parser: MemcachedPhpBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
Fully initialised
MessageCache::load: Loading en... 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
MWCryptRand::realGenerate: Generating cryptographic random bytes for LoginForm::setLoginToken/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.
QuickTemplate::__construct was called with no Config instance passed to itIP: ****:****:****:****:****:****:****:****
Connected to database 0 at dbclus01-int.some.nl
OutputPage::sendCacheControl: private caching;  **
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
[runJobs] Running 1 job(s) via '/wiki/index.php?title=Special%3ARunJobs&tasks=jobs&maxjobs=1&sigexpiry=1417960979&signature=7e34d77cc66f5a8f8db8ab8e65f4feef8d4b4322'
[runJobs] Failed to start cron API: received 'HTTP/1.1 302 Found
'
Request ended normally

Is there way to disable cookie login ?

i got the same errorː

uses cookies to log in users. You have cookies disabled. Please enable them and try again.

then added the following lines to LocalSettings.phpː

$wgDebugToolbar = true; $wgDebugLogFile='/var/log/mediawiki/mediawiki.log'; $wgShowExceptionDetails = true; $wgShowDebug = true; $wgDevelopmentWarnings = true;

and the debug shows errorː

[memcached] Memcached error: Error connecting to 127.0.0.1:11211: Connection refused

[MessageCache] MessageCache::load: Loading en... global cache is empty, waited for other thread to complete, global cache is empty, could not acquire status key., loading FAILED - cache is disabled

then commented out the following lines in LocalSettings.phpː

$wgMainCacheType = CACHE_MEMCACHED; $wgParserCacheType = CACHE_MEMCACHED; # optional $wgMessageCacheType = CACHE_MEMCACHED; # optional $wgMemCachedServers = array( "127.0.0.1:11211" ); $wgSessionsInMemcached = true; # optional

I was able to login without error after.

This post was posted by 199.64.6.150, but signed as 20.1.3.4.

Its certainly not the best solution, but simply disabling caching helped for us.

Finaly is found the problem en solution

THe problem is only there when session.referer_check = On is set .

So set session.referer_check = off en problem solved