Hi there,

I'm using Xitami 2.4d11 and encountert login problems like some other users around the forum. After entering my admin login and password I was sent to the login page agin (without a "wrong password" message of course). The cookie variables in setup_options.php where fine (untouched) and after checking my cookies I realized that no cookie was set at all.
After some hours of testing and stepping through the sourcecode I noticed that everytime a usercookie is set, it is deleted before (by setting an already expired time-to-live). I commented the deletion out (secure_bb_admin.php(103)) and everything worked fine.
I found out that deleting and setting the same cookie in two succesive calls of setcookie() isn't supported by (my?) xitami webserver.

To test that I wrote a sample script and ran it on xitami and apache:
cookie_test.php
// delete the cookie
setcookie('crunch','', (time()-2592000));
// set the cookie
setcookie('crunch','somedata', time()+108000);

// set a test cookie so we're able to check if 'crunch' was set
setcookie('test','testdata', time()+108000);

// if page is reloaded print cookiedata
if (isset($_COOKIE['test']))
{
// 'test' was set so let's check if 'crunch' was set also
if (isset($_COOKIE['crunch']))
{
echo '<b>cookie was set</b>.</br>delete and (re)set in one step is supported';
}
else
echo "<b>cookie wasn't set</b>.</br>just overwrite the old one instead of calling <i>setcookie()</i> twice for the same cookie";
}
else
echo 'press <b>reload</b> in your browser to see if the cookie was set';

On my Xitami the 'crunch' cookie wasn't set whereas on apache it was.

I then commented deleteMyCookie() out in bb_cookie.php, bb_func_login.php and secure_bb_admin.php and everything works flawlessly.

My question is:

Why do you delete the cookie right before you set it again? Filling it with new data is also like deleting the old one. As I said I just commented deleteMyCookie() out when it was followed by setMyCookie(). If the content of the cookie is to be overwritten anyway then why delete it?
I don't think that the functionality of miniBB would be harmed if you call setMyCookie() without calling deleteMyCookie() right before.
Since that change the forum works totaly fine with Xitami.

Well... first of all, you don't need to comment deleteCookie() in all possible places. You need to comment setcookie function in deleteCookie() itself. So this function is called, but does nothing.

Second... deleting of the cookie before setting it was introduced from the earliest versions of miniBB. Already more than 5 years passed, and nobody from us does remember why this was implemented. Probably, there were some problems these times with oldest versions of browsers (like Netscape 4.x if you remember this), which didn't set cookies correctly if they were not deleted previously; i.e. they didn't overwrite them. Probably, it's just the reason for stability, that cookie MUST be set if it is removed before; and I am wondering why it's not working in Xitami...

Yepp that would have definetily saved me some replacement work but I wanted to save the calls, even if deleteCookie() does nothing in itself (I don't think that php is this smart to check if a function does anything at all and just "overhears" it's calls).

I'm wondering if it's really xitami or some configuration statement in my php.ini (cookies are sent through an html-header and maybe there are some php header-caching options that are configured differently in my standard php release than in an apache release which has php bundled and already configured with it). I don't see the guilt in my webserver here. PHP.exe produces output and my Xitami just streams it to the client who made the request.
--As far as I remember there was a quote on php.net which said "don't touch cookies twice"... I'll post it if I can find it again.

English is not my native language by the way. Howewer I hope that I can make myself clear.

And thanks for your reply. I appreciate that!

English is not my native language by the way. Howewer I hope that I can make myself clear - ours too :) Don't worry - your English is much better than some natives write here.

So, I still think it's a Xitami problem. Definitely, there is no restrictions on setting cookies twice - it means only, 2 headers are sent to the browser one after another. But you could try another thing - uncomment //$metaLocation='go'; parameter in setup_options.php so it looks like $metaLocation='go';.

And I was a little bit wrong about commenting setcookie in deleteMyCookie function... because in that case, you won't be able to logout :) So it i really better just to comment this function everywhere it's necessary.

A million thanks! Had the same problem on my Xitami test server.

Spent several hours tracing through the code. I knew it was a problem with the cookies but simply didn't dawn on me that the line deleting the cookies before the set cookie line was causing the problem.

I had tried many, many combinations of setting in the setup_options.php file but nothing solved the problem. Your solution worked perfectly!

I would only hope that someone can discover why this seems to only happen on a Xitami server.

To the minibb team: Suggest you remove the delete cookie lines in future releases. There alot of us who use Xitami and it would be a shame for people to get turned off from your excellent software because of this.

Honestly I don't know a lot of people who "use Xitami", and basically, such problem earlier appeared on IIS servers too (may be it appears on other server we don't know about). That's why the special option was introduced.

Regarding cookie deletion - it's all stored under bb_cookie.php file which is not core-destructive. So you can edit in on your wish and remove unnecessary line keeping the upgrading possibility.