setcookie() no work

Cookie Monster Sad

[cmarshall]

I am having the wackiest problem: setcookie() works fine on my machine and another directory on the same ISP, but not on the customer's directory.

It's a pretty standard domain/session cookie:

$cookie_name = "_admin";
$cookie_duration = 0;
$cookie = $_POST['in_login']."\t".$_POST['in_password'];
setcookie ( $cookie_name, $cookie, $cookie_duration, '/' );

One thing I do is use ob_start(), etc. to optimize my output, but that doesn't seem to be the issue.

Anyone have any experiences with cookies to share?

[eelixduppy]

Is it simply not setting the cookie at all? Or just not for the path that you want? Your code is correct.

[cmarshall]

Your code is correct.

Exactly. It is not setting it at all. I check domain cookies with Web Developer Toolbar, and get nada.

I use another server, with the same ISP, as a testing and staging server, and that works fine.

When I get a bit more time, I'll do a phpinfo() and compare results.

I was just wondering if anyone has had issues with setting cookies.

I'll get it eventually. The main difference between this site and the last one (in the same server) is the page compressor, using PHP's output buffering (ob_) stuff. I suspect that it may have something to do with it, but a quick check this morning, where I made it a transparent pass-through, and added the setcookie() to it made no difference. Later tonight or tomorrow, I'll try removing all the ob_ stuff, and see if that does it.

[jatar_k]

try setting the domain portion explicitly

[cmarshall]

try setting the domain portion explicitly

Holy s%$t. That did it. Thanks!

Isn't that supposed to be an optional parameter? I've never set it before.

In any case, I just set it to $_SERVER['SERVER_NAME'], and that does it.

Can this be set in the php.ini stuff? I've not run into this before. As I said, it isn't necessary on my default PHP 5 installation, or even on another server run by the same ISP, and (ostensibly) the same setup.

My ISP has a nasty habit of doing major tweaks in the background without letting us poor schlubs know.

[jatar_k]

I always set the domain param

sometimes you have to play with it a bit to get it right, that's always my first thought

I have had trouble before and I haven't used cookies in years so I doubt it was an ISP tweak

it's good to be explicit about what domain anyway, makes me feel more secure

[cmarshall]

Okay, so I look at my cookie, and I see Jatar's comment about not using cookies. I was using a session cookie anyway, so why not go "all the way," and use PHP session support? Not only that, but when I started specifying the domain, the cookie started working on the deployment server, and stopped working on both my test servers.

So, I switch from cookies to sessions. Works great!

On my laptop and the other test server on my ISP.

But not on the deployment server. This is the same server that gave me agita over cookies without the domain specifier.

There doesn't seem to be much I can do. I'm no session expert, so maybe I'm missing something, but it should be even simpler than cookies. Here's what I do:

$cookie_name = "_admin";
session_start();
if(!$_SESSION[$cookie_name]){
$cookie = $_POST['in_login']."\t".$_POST['in_password'];
$_SESSION[$cookie_name] = $cookie;

}

The symptom is that $_SESSION doesn't work on any subsequent pages, so the session is not being propagated.

I see the PHPSESSID cookie is being properly set. It's just that $_SESSION isn't being filled.

Any ideas?

[cmarshall]

Heh-heh. Just an update.

I asked my ISP about this behavior, and it quietly "fixed itself" overnight.

I fully expect to get a "WFM" email today.