Wikimedia Bugzilla is closed!

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
distribution.

Whoopsy. Wasn't on my usual machine; didn't think to look. :)

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.

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?

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.

Thanks.

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?

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.

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).

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.

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:
     davek@baka.com
     davek@clarityconnect.com

"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

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
[http://bugzilla.wikimedia.org/show_bug.cgi?id=3826 3826] as reported many
months ago.

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)

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)

Hi, 
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).
session.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?

Thanks.

Please look at bug 3826 comments 4 and 5, try the fix there and
let us know if it fixes the issue.

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.

Example 
The following will result in a "cookies disabled" error when I try to login.
http://tss_svr_2/wiki/index.php/?title=Special:Userlogin&returnto=Main_Page

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.

Thanks...

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.