I completely agree. Where I work I found out that many users were copying the cookies, and renaming them, from a users workstation who had access to a particular in-house web site. They were having trouble logging in to the web page so they just raided the cookie jar. Turned out none of them had ever requested access. Cost money and patience to call the help desk and request an ID/password! Thinking cookies are good security practice is like thinking your cookie jar is safe from your kids. They'll always get into them. | [reply] |
That's a great link - thanks - I think it's a great strategy that I'll probably use on the next version of the application. BTW, my code does allow for short cookie expiration times (like just for the session). However, this strategy doesn't solve my problem, sadly. If, for some reason, the application can't either write the cookie, or read the cookie, it kinda doesn't matter what the cookie is. The problem remains. | [reply] |
Sorry, I should've mentioned I don't know what might help you, and was just giving some general advice.
FWIW, I've heard of some versions of IE caching pages including headers, leading to strange behaviour with cookies. To see if you suffer from caching woes, you can try the following snippet which I've filed away under overthetop_anticache.pl:
use POSIX qw(strftime);
print header(
# date in the past
-expires => 'Sat, 26 Jul 1997 05:00:00 GMT',
# always modified
-Last_Modified => strftime('%a, %d %b %Y %H:%M:%S GMT', gmtime),
# HTTP/1.0
-Pragma => 'no-cache',
# HTTP/1.1
-Cache_Control => join(', ', qw(
no-store
no-cache
must-revalidate
post-check=0
pre-check=0
)),
);
Update: fixed date as per davis.
Makeshifts last the longest. | [reply]
[d/l] |
-expires => 'Mon, 26 Jul 1997 05:00:00 GMT',
Dare I point out that 26 July 1997 was actually a Saturday?
And, yes, I hate the fact I checked too. ;-)
davis
Is this going out live?
No, Homer, very few cartoons are broadcast live - it's a terrible strain on the animator's wrist
| [reply] |