Eric Sammer wrote:
> What is weird is that the Apache::Cookie object DOES exist, it's just
the value
> that's all wacked out or just plain missing.
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:
if((exists($cookie->{user_id})) && (defined($cookie->{user_id})))
Just doing if(defined .. Checks to see if the value of the key is
defined. If the
key did not exist previously it may be created by this process. The key
can exist but
hold an undefined value.
> The problem is that the logout handler (which expires the user_id
cookie) kills the
> cookie and redirects to / ok, but when the GroupAccess handler checks
if the cookie
> exists (during the / request), $cookies->{user_id}* is defined, but
the value seems to
> be an empty string ala "".
Is this an internal redirect, or a redirect sent from the browser ? 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.
If it's coming back from the browser are you sure that the browser isn't
sending you an empty
Cookie? Maybe some users have broken browsers ?
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,
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 be
more at peace if you
just checked to see if the value of the cookie was valid. 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 ;)
(Just for the record I don't actually use Apache::Cookie myself I look
in and set the headers)
Rob Lambden
