Last modified: 2010-05-15 15:48:17 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5535, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3535 - Can not login, claims cookies are disabled
Can not login, claims cookies are disabled
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
PC Windows XP
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2005-09-23 06:19 UTC by Serkan Cabi
Modified: 2010-05-15 15:48 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Serkan Cabi 2005-09-23 06:19:27 UTC
I am running Mediawiki 1.5rc4 with PHP 5.0.5. I can create accounts but cannot login. Error message is "XXX ses cookies to log in users. 
You have cookies disabled. Please enable them, then log in with your new username and password." But I am pretty sure that my cookies 
are enabled. I can login other mediawiki sites. Error persists in both Mac and Windows machines with several different browsers.
Comment 1 Rowan Collins [IMSoP] 2005-09-23 11:18:49 UTC
Comment accidentally e-mailed to mailing list by Rob Church:

Are cookies enabled in your MediaWiki configuration, or more
precisely, the local PHP configuration? As the message occurs when
connecting to that, assume that the issue lies with your local
Comment 2 Rob Church 2005-09-23 14:34:17 UTC
Whoopsy. Wasn't on my usual machine; didn't think to look. :)
Comment 3 Serkan Cabi 2005-09-23 20:45:54 UTC
I think my local settings are OK because 1.4.10 has no problem with login and cookies. But I can not run it because it has its own 
problems. Running any search gives fatal error (I think due to incompatibility with PHP 5.0.5) for example.
Comment 4 Rob Church 2005-09-23 21:20:02 UTC
Just to confirm/clarify: I ought to have said, "assume the issue lies with the
server configuration". I haven't actually noticed any issues on my test wiki
(IIS, PHP5, mySQL 4.1) but perhaps I'm just lucky. What is the fatal error you
are receiving?
Comment 5 Serkan Cabi 2005-09-23 21:29:11 UTC
I am having the fatal error in 1.4.10 release not in 1.5rc5. The error is:

Fatal error: Only variables can be passed by reference in xxx/mediawiki-1.4.10/includes/SearchEngine.php on line 36

1.5rc5 only has login/cookie problem I described above.

Comment 6 Rob Church 2005-09-23 21:50:27 UTC
Ah. Teach me to check your version in future; yes, MediaWiki 1.4 uses functions
no longer available in PHP 5. As the problem occurs on other machines of
different configurations, I'll check; PHP's configuration file (php.ini) is
definitely set up to allow the use of cookies, and all the supplemental cookie
stuff like paths, etc. is set correctly?
Comment 7 Joe Presbrey 2005-09-24 21:29:28 UTC
Hey guys, solved this problem for Serkan...

in Setup.php around line 121, the session name is prefixed with the database
name.  This breaks when the database name contains a '+', i.e: cabis+wiki.  The
session name is set fine for that instance of the script but either (I didn't
bother checking which) PHP passes the session cookie or when the browser passes
it back next time, it sends the cookie name replacing the plus [+] with an
underscore [_].  As the database name still contains a plus, the check for the
session cookie fails because the browser is sending back a cookie with an
underscore instead of a plus.

Hope I explained that concisely and well enough that its an easy fix!  Thanks.
Comment 8 Brion Vibber 2005-09-25 06:12:38 UTC
Don't put special characters in your database name; that will likely 
break many, many things. It's assumed to be a standard-form identifier 
(alphanumeric and underscores).

Comment 9 Joe Presbrey 2005-09-27 17:27:24 UTC
Brion: unfortunately this is not possible.  MIT uses '+' as a delimeter between
an MIT Athena's username and their chosen database name.  Using underscore was
considered first but because we allow users to have an underscore in their
Athena username, this becomes impossible.  If this issue can be fixed, it would
be great.  We'd love to be able to recommend MediaWiki to the student population
for all their wiki needs, but I'm also comfortable simply providing a patch file
for users who _must_ use MediaWiki as I have for Serkan.
Comment 10 davek 2006-07-25 03:19:45 UTC
New to WIKI-, wanted to edit an entry.

So, must get an ID - which requires use of cookies.

Got told cookies are disabled.  Knowing this to NOT be true:
     Disabled cookies, tried to log into Yahoo - got rejected as expected.
     Enabled cookies and SUCCESSFULLY logged into Yahoo.
     Demonstrating that I CAN enable/disable cookies.

Using Netscape 6.2.2   OS 9.0.4

SO:  Cookies DO WORK on my MAc (and getting to where I could enter this
complaint required use of cookies - which DID get me here). 

One oddity:
    I have ONE site, but ISP support lets me use, as synonyms:
Comment 11 Joe Knall 2006-08-11 22:52:57 UTC
"You have cookies disabled. Please enable them..."
set "session.use_cookies = 1" in php.ini
or (workaround, if you don't want this)
put the line 
ini_set('session.use_cookies', '1');
on top of index.php (and repeat this step after upgrades)
maybe one should simply add a hint to the docs;
if session.use_cookies is false, wiki sets cookies "wikidbUserID" and
"wikidbUserName" but not "wikidb_session" so login doesn't work
Comment 12 Marc Quinton 2006-09-23 09:46:45 UTC
I have a login probleme with MediaWiki 1.7.1. My domaine name contains a dot and
cookie name generation is wrong. Cookies must not contain a dot. So we need to
fix it in includes/Setup.php, line 119, just add : $wgCookiePrefix =
str_replace('.', '_', $wgCookiePrefix);

This probleme is exactly the same than
[ 3826] as reported many
months ago.
Comment 13 Guillaume Outters 2006-10-02 22:53:40 UTC
Just got this bug too. Added $wgCookiePrefix = strtr( $wgCookiePrefix, array( '.' => '_' ) ); at line 126 (mediawiki-1.7.1 too… that's curious), and it works. Aren't they any other chars 
that should go away?

The problem is (in my case) that Safari accepted cookies having dots (as seen in Preferences > View cookies), but then resubmitted them with dots replaced by underscores (as seen 
with tcpdump). Even if I didn't search for pre-RFC Netscape specs, I suspect there must be, as Marc said, something more or less forbidden with dots in cookie names.

(see Anders' strtr in bugz 3826 for a far better filter)
Comment 14 wonesek 2006-12-22 13:53:55 UTC
Same problem with mediawiki-1.8.2

Added $wgCookiePrefix = str_replace('.', '_', $wgCookiePrefix); after :

if ( $wgDBprefix ) {
	$wgCookiePrefix = $wgDBname . '_' . $wgDBprefix;
} elseif ( $wgSharedDB ) {
	$wgCookiePrefix = $wgSharedDB;
} else {
	$wgCookiePrefix = $wgDBname;

But it doesn't change anything... :(

my php.ini contains :

session.use_cookies = 0
session.auto_start = 1

So, in top of my index.php file i added :

ini_set('session.use_cookies', '1');
ini_set('session.auto_start', '0');
ini_set('session.use_only_cookies', '1');

But nothing. In fact, i can log on only if i use "remember my password
(cookie)". But even then, i got the message "Problème d’identification:
... utilise des cookies pour la connexion mais vous avez les cookies désactivés.
Merci de les activer et de vous reconnecter." (Cookie disabled message)
Comment 15 Tim Deeming 2007-04-16 12:45:39 UTC
I'm new to MediaWiki and am having problems.  I get like so many others a 
warning that the cookies have been disabled.  
I can edit on my localhost without any problems.  However when I try to edit a 
document from another host, I get the error about the cookies.
My php.ini file has the following settings, which appear to be correct.
; Whether to use cookies.
session.use_cookies = 1
; Name of the session (used as cookie name). = PHPSESSID
; Initialize session on request startup.
session.auto_start = 0
; Lifetime in seconds of cookie or, if 0, until browser is restarted.
session.cookie_lifetime = 0
; The path for which the cookie is valid.
session.cookie_path = /
; The domain for which the cookie is valid.
session.cookie_domain =

Any tips as to what the problem is?

Comment 16 Antoine "hashar" Musso (WMF) 2007-04-16 13:04:05 UTC
Please look at bug 3826 comments 4 and 5, try the fix there and
let us know if it fixes the issue.
Comment 17 Tim Deeming 2007-04-17 07:42:13 UTC
Thanks for the input.  I tried out the comments 4 and 5... and some of the ones on this bug report too.  
Unfortunately it didn't change anything for me.  However I made some more experiments... and narrowed the 
problem down... and found a work-around... so I will explain below.

I am using MediaWiki Version 1.9.3 on the latest xampp-win32-1.6.0a on a win xp professional.  The PC is 
connected to our companies intranet.  The PC-name is "tss_svr_2"... and that seems to be the core of the 
problem.  This is the NetBios Name and the name used for our DNS server.

The following will result in a "cookies disabled" error when I try to login.

By changing "tss_svr_2" to the "actual" IP address, I have no problems and can login in properly

Likewise if I create an entry in the "hosts" file and give it a name like "TSS" it will work fine too... but 
if I create a name with an underscore... I get the same problem again.  Actually it seems a bit strange as 
the solutions presented above, replace the "." with an "_".

I suppose my problem will be completely fixed if I request our domain administrator to change the name of my 
PC... but they aren't always very cooperative... and you need to get them when they are in a good mood... 
which isn't often...  So when I get up the courage to change it... I'll let you know if it didn't work.

Anyway, I hope the helps give some insight on a problem that might be faced with other beginners like me.

Comment 18 Brion Vibber 2007-04-24 20:31:01 UTC
I'm closing this bug; there's like different people over two years with four
different site-specific configuration problems on this bug and no coherent issue
to move forward on.

Note You need to log in before you can comment on or make changes to this bug.