On Mon, 30 Apr 2001, will trillich wrote:
> Date: Mon, 30 Apr 2001 18:17:11 -0500
> From: will trillich <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: forbidden vs. cookie
>
> On Mon, Apr 30, 2001 at 03:46:17PM -0400, Ken Y. Clark wrote:
> > Here is some code I've used in the past in a mod_perl app to
> > set a cookie and do a redirect at the same time. I believe it
> > works for most browsers -- or at least this code has been
> > working for over a year and I haven't heard too many complaints
> > about this piece (that I can think of).
> >
> > my $cookie = Apache::Cookie->new($apr,
> > -name => 'foo',
> > -value => 'bar',
> > -expires => '+30m',
> > -domain => '.domain.com',
> > -path => '/',
> > );
> > $cookie->bake;
> >
> > $apr->method_number(M_GET);
> > $apr->method('GET');
> > $apr->headers_in->unset('Content-length');
> > $apr->headers_out->add('Location' => '/foo');
> > $apr->status(REDIRECT);
> > $apr->send_http_header;
> > return OK;
>
> i presume $apr is as in "sub handler { my $apr = shift; ... " ?
Yes. I'm sorry, I should have been more explicit. Actually, the
first line of the handler() is this:
my $apr = Apache::Request->new( shift() );
> and is this in PerlAuthhandler?
No, I used this in a PerlHandler as the <Location> for logging a user
into the mp3.boston.com site. Again, I believe my method works --
though I never tested it exhaustively in every conceivable browser. I
simply made sure it worked on the major browsers (Netscape and IE) on
Linux, Solaris, Mac and Windows. I wanted to do exactly what you
want: Set a cookie (mine being the "logged in" information) and
simulaneously redirect the user to their "home" page on the site.
I do, however, use a PerlAccessHandler like so:
<Location /upload>
PerlAccessHandler BGEP::MP3::VerifyLogin
ErrorDocument 403 http://mp3.boston.com/login/login.shtml
</Location>
It checks every request for a valid "session" cookie (which contains
nothing more than the user's id and will fail to be returned when the
cookie expires).
> after seeing the 'expires' dilemma brought about by poorly
> configured client system clocks, what advice should we follow?
> (what's the Official Party Line on expiring cookies?)
I'm not really sure how to answer your question. I have usually
understood that the client handles all of this. That is, you tell the
client that the cookie is good for 30 minutes, and it figures out when
those 30 minutes have expired and then quits sending a valid cookie back
to the server. Is that right? Anyone? Anyone? Bueller?
ky
