Cookie won't unset

Question

OK, I'm stumped, and have been staring at this for hours.

I'm setting a cookie at /access/login.php with the following code:

setcookie('username', $username, time() + 604800, '/');

When I try to logout, which is located at /access/logout.php (and rewritten to /access/logout), the cookie won't seem to unset. I've tried the following:

setcookie('username', false, time()-3600, '/');

setcookie('username', '', time()-3600, '/');

setcookie('username', '', 1, '/');

I've also tried to directly hit /access/logout.php, but it's not working.

Nothing shows up in the php logs.

Any suggestions? I'm not sure if I'm missing something, or what's going on, but it's been hours of staring at this code and trying to debug.

I was able to fix it at the end by passing all the setcookie() parameters in. I'll definitely look into it a little more when I get a chance. — Jordan Satok, Mar 23 '10 at 05:43

score 1 · Answer 1 · answered May 15 '12 at 18:41

1

Seems to be a server issue. My last domain was pretty relaxed on PHP error handling while the new domain shows every error. I'm using both sites side by side and the old one removes the cookie as it should.

answered May 15 '12 at 18:41

Geo

11
1

score 1 · Answer 2 · answered Mar 23 '10 at 05:00

How are you determining if it unset? Keep in mind that setcookie() won't remove it from the $_COOKIE superglobal of the current script, so if you call setcookie() to unset it and then immediatly print_r($_COOKIE);, it will still show up until you refresh the page.

Try pasting javascript:alert(document.cookie); in your browser to verify you don't have multiple cookies saved. Clear all cookies for the domain you're working on to make to sure you're starting fresh. Also ini_set(E_ALL); to make sure you're not missing any notices.

score 0 · Answer 3 · answered May 28 '13 at 20:02

0

I had a similar issue.

I found that, for whatever reason, echoing something out of logout.php made it actually delete the cookie:

echo '{}';
setcookie('username', '', time()-3600, '/');

answered May 28 '13 at 20:02

Nate

2,940
3
22
24

score 0 · Answer 4 · answered Mar 23 '10 at 04:11

0

Is there perhaps a timezone issue here? Have you tried setting using something farther in the past, like time() - (3600*24)? PHP's documentation says that the internal implementation for deleting cookies uses a timestamp of one year in the past.

Also, you should be able to use just setcookie('username', false); without passing an expiration timestamp, since that argument is optional. Maybe including it is confusing PHP somehow?

answered Mar 23 '10 at 04:11

awgy

16,596
4
25
18

Just passing setcookie('username, false); doesn't work either. I've tried clearing my cookies, multiple browsers, multiple machines, multiple servers... no what's going on! – Jordan Satok Mar 23 '10 at 04:22
You have to use the same domain, path, secure, and httponly as when the cookie was set. (This isn't always true, but it is what the browsers are supposed to do.) – phorgan1 Aug 23 '11 at 09:02

score 0 · Answer 5 · answered Mar 23 '10 at 04:12

How you use cookies data in your application?

If you read the cookies and check if username is not false or not '', then setting it to false or '' will be sufficient, since your application will ignore the cookies value.

You better put some security in cookies value, to prevent user change it's value. You can take a look of CodeIgniter session library, see how CI protect the cookies value using hash. Unauthorized value change will detected and the cookies will be deleted.

Also, CI do this to kill the cookies:

// Kill the cookie
    setcookie(
          $this->cookie_name,
          addslashes(serialize(array())),
          (time() - 31500000),
          $this->cookie_path,
          $this->cookie_domain,
          0
        );

score 0 · Answer 6 · answered Mar 23 '10 at 04:31

0

You can delete cookies from javascript as well. Check here http://www.php.net/manual/en/function.setcookie.php#96599

answered Mar 23 '10 at 04:31

pinaki

5,393
2
24
32

score 0 · Answer 7 · answered Mar 24 '17 at 08:08

I had the same issue; I log out (and I'm logged out), manually reload the index.php and then I'm logged in again. Then when I log out, I'm properly logged out.

The log out is a simple link (index.php?task=logout). The task removes the user from the session, and "deletes" (set value '' and set expiry in the past) the cookie, but index.php will read the user's auth token from the cookie just after this (or all) task (as with normal operations). Which will reload the user. After the page is loaded the browser will show no cookie for the auth token. So I suspect the cookie gets written after page finish loading.

My simple solution was to not read the cookie if the task was set to logout.

score 0 · Answer 8 · answered Apr 09 '11 at 18:44

A simple and convenient way, is to use this additional functions:

function getCookie($name) {        
    if (!isset($_COOKIE[$name])) return false;
    if ($_COOKIE[$name]=='null') $_COOKIE[$name]=false;
    return $_COOKIE[$name];
}

function removeCookie($name) {
    unset($_COOKIE[$name]);
    setcookie($name, "null");
}

removing a cookie is simple:

removeCookie('MyCookie');
....
echo getCookie('MyCookie');

score -2 · Answer 9 · answered Mar 23 '10 at 04:09

-2

use sessions for authentication, don't use raw cookies

http://www.php.net/manual/en/book.session.php

answered Mar 23 '10 at 04:09

Martin

32
2

session and cookies is only a way to store a persistent data between stateless http connection. One of the purpose for storing persistent data is for authentication. No matter which you are using, sessions or cookies, you must always put the security measure to prevent unauthorized access to your application. Session can be hijacked, cookies value can be changed. Security is not using which, but to prevent the bad guy exploit it in the first place. – Donny Kurnia Mar 23 '10 at 04:18
I said don't use raw cookies like this: setcookie('username', $username, time() + 604800, '/'); if you're so concerned about session hijack then store an IP into the session and compare ... or something. this is so trivial. – Martin Mar 23 '10 at 14:32
@Martin, storing the IP won't always protect you from a session hijack. If you're on a network which is behind a NAT, as most public access points will be then everyone on that network will appear to have the same IP. The real way to protect against session hijacking is to use HTTPS. If for some reason you don't want to use HTTPS digest authentication is ok, but I wouldn't rely on it for strong security. – Peter Bagnall Aug 03 '12 at 23:13

Cookie won't unset

9 Answers9

Linked