RE: Apache::Cookie - weird values returned...
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
Re: Apache::Cookie - weird values returned...
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
Re: Apache::Cookie - weird values returned...
Eric Sammer wrote: 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. The HTTP headers do not support relative dates as far as I know. Thus when you specify a relative date the code must claculate the expiry date for you and send it back to the browser. If a user has their date and time set such that the cookie is still valid they will continue to return it. You might want to consider invalidating the cookie by setting the content to an empty value as well as setting the expiry date. This would then mean that even if they still think it's valid they have no value, only an empty string (which, AFAIK, most browsers will treat as an invalid cookie). You might be more comfortable making the expiry more than a day old. I logged onto a machine the other day and started getting browser messages that my server's security certificate had expired or was not yet valid. It turned out that the RTC on the machine was set to 1980. Maybe the user just wanted to relive the 80's ;) Rob Lambden
Apache::Cookie - weird values returned...
All:
I've got a strange Apache::Cookie issue that seems to have recently
snuck up on me, although I've seen similar behavior in the past.
I have a PerlAccessHandler called GroupAccess that handles all access to
a site**. If there's a user_id cookie, it pulls urls allowed to that
user from a db, otherwise, an anonymous set of urls that are allowed -
certainly not rocket science. 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 . This really makes things difficult. 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. Could it be bug in
Apache::Cookie that only shows up during internal redirects (and when
I'm not looking)? This problem is incredibly difficult to reproduce as
it only happens about 1 out of ever 30 - 40 times... That said, when it
does happen, users complain and that's not cool at all.
* $cookies is a hash ref with cookie names as keys and Apache::Cookie
objects as values.
** The site in question: http://www.bluemonkeystuff.com
Thanks in advance!
--
Eric Sammer
[EMAIL PROTECTED]
http://www.linuxstep.org
