Rob Lambden wrote:
I've had problems with scripts and mod_perl code before where I
inadvertently create
keys in a hash when I'm testing to see if they exist. I now always use
something
Like:
i 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. ;)
> If the
key did not exist previously it may be created by this process. The key
can exist but
hold an undefined value.
again, 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.
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).
If
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.
yea... 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)... ;)
If it's coming back from the browser are you sure that the browser isn't
sending you an empty
Cookie?
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.
Maybe some users have broken browsers ?
with the current state of things, i'm sure that's part of it. :)
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.
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?
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.
Could you make do with per-session cookies (which have no expory date,
but are only valid for
the duration of that browser session) ?
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.
Although it's helpful to get to the bottom of any issue, you might be
more at peace if you
just checked to see if the value of the cookie was valid.
yea... 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."
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 ;)
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. ;)
(Just for the record I don't actually use Apache::Cookie myself I look
in and set the headers)
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.
thanks for the response... i'll give some of these ideas a shot (again,
where applicable).
--
Eric Sammer
[EMAIL PROTECTED]
http://www.linuxstep.org