Cookie time outs. Yikes!

Anon

I was trying to set a cookie (for testing purposes) to expire 2 minutes into the future, e.g., time()+120

But every time I would run my test script, the cookie expired before I could even test it! I noticed that the server I am on uses GMT. So any cookie I would set for EST (my time zone) would be 5+ hours due to the time() call. So a cookie set to expire at, say 12:02, would actually expire at 17:02. So that can't be the problem, I thought.

Then I noticed that my local clock was 3 minutes fast compared to local EST. So it appeared to me that this was the problem. But the question remains, even if that is true, my local clock would have to be 5 hours + 3 minutes fast for the cookie to expire before it could be sent, no?

My question is, do cookies use your local machine time or your server time for expiration times?

adamd1

Hm.

Typically it's a better idea to set it to a more reliable, four-digit value. I haven't run into that so much since I stopped actually using cookies. Lots of the sites I build were visited by security-conscious types and you could never guarantee that cookies would ever set, or if they did set that they would time out properly due to browser settings, etc. So I switched 100% to session ids, which PHP supports really well.

Try time()+0120; // four digits hey?

Or just try a slightly larger time increment.

time()+1000;

Also: try printing out the time value you want to see. Make sure it's actually calculating the time value you're hoping to see.

Anon

Thanks. Yes, I know that some people turn off cookies, or at least set the option to notify (what a pain that is to have to sift thru all those incoming cookies, but it sure is an eye opener!).

I originally came to this issue due to a security reason. I wanted my users to have to check "Yes" or "No" on a "Terms of Agreement" form before they could proceed to the next form in a series. If they check "No" (I don't accept your terms) they get redirected back to the main page.

But what about those hackers who know how to just type in the page address in the browser address box? So I decided to send them a cookie first. If they refuse it, then the "next page" checks the null value, and back they go to the main page.

The only problem with this scheme is that they could accept the "terms" page the first time around, get the URL of the "next page", then go back to the main page. They now have the cookie (if set to expire at the end of the session). So they can now type in the web page address -- and theoretically say that they never saw any "Terms of Agreement", na nah na nah na na!

I know this is very picky, but you must guard against any loop holes, lest someone decides to sue your ass off, and the judge says to you, "You lose."

So I decided to set a time limit on the cookie, like 30 seconds. This way, the hacker would not have time to go back to the main page, type in the page address, and come back in as if nothing at all had ever happened (unless he was Clark Kent).

Unfortunately, 30 seconds will just not work, esp. if someone's local clock if off by more than that with the server time . . .

which is where I came in :-)

What a conumdrum, eh?

I wonder if Sessions (which I am now exploring) might have a solution here. Call me paranoid, but you never know who is trying to pull what out there! Or, as they say, better safe than sorry.