Rob Lambden wrote:
I've had problems with scripts and mod_perl code before where Ii always use either defined or exists as appropriate to avoid these errors. i've gotten bitten in the bottom by the same things many times in the past... i learned my lesson. ;)
inadvertently create keys in a hash when I'm testing to see if they exist. I now always use
something
Like:
> If the
key did not exist previously it may be created by this process. The keyagain, in this case, the key is an Apache::Cookie object which couldn't accidentally be created as a "simple" type like a string key can.
can exist but hold an undefined value.
Is this an internal redirect, or a redirect sent from the browser ?the logout handler expires the cookie, sets the Location header, and returns REDIRECT. in other words, it's not internal nor a subrequest (unless a returned REDIRECT with a Location header is still considered a subrequest - that would be a surprise to me).
Ifyea... unfortunately, that's not the case here... the browser regains control enough to handle the Set-Cookie (again, unless my perl/mod_perl/cgi books are all out of date)... ;)
it's internal then the cookie will still exist unless you deleted the key yourself, and if
you run the request
As a sub-request it can pick up the submitted cookie again even if you
have deleted the key
on your parent request object.
the cookie is a real cookie (in the headers) with the absence of the value. specifically, the return value of the Apache::Cookie->value() method.If it's coming back from the browser are you sure that the browser isn't sending you an empty Cookie?
with the current state of things, i'm sure that's part of it. :)Maybe some users have broken browsers ?
that said, there's always a limited set of options on that front. most of my (personal) testing is with mozilla on linux built from source (gentoo portage, actually) but similar behavior is seen on my mac os x boxes.
the expire *i'm* specifying is just a relative '-1D' to cause the browser to drop it. if there's a better way, i'm certainly open to suggestions.You might also want to check hoe the cookie gets expired. What is the expiry date that is set on the Set-cookie: header that goes back to the client, and what is the date on that machine?
Could you make do with per-session cookies (which have no expory date,actually, all of these cookies are per-session which is why this isn't a "hey, the building is on fire!" sort of problem. the logout is one of those superfulous things that might be needed should the non-tech staff force us to add the dreaded "save my username/password" feature to the site. either way, i'd rather try and get the problem out of the way prior to such escalation.
but are only valid for the duration of that browser session) ?
Although it's helpful to get to the bottom of any issue, you might beyea... i suppose that's an option (and it *was* like that). i just get scared when something isn't working exactly as i understand it to be. it's that age old developer mantra of "unpredictable working code is worse than predictable broken code."
more at peace if you
just checked to see if the value of the cookie was valid.
damn browsers... damn cookies. i'm still waiting (and will be for a long time to come) for two things: working stateful web development and flying cars... something tells me the latter is a more attainable goal. ;)After all, who's to say that the cookie they're sending you is actually the same as the one you sent them in the first place ;)
i used to do that all the time too. i've always felt that abstraction prevents errors in the long run (or at least makes them easier to find). being wrong sucks.(Just for the record I don't actually use Apache::Cookie myself I look in and set the headers)
thanks for the response... i'll give some of these ideas a shot (again, where applicable).
--
Eric Sammer
[EMAIL PROTECTED]
http://www.linuxstep.org
