You are viewing a plain text version of this content. The canonical link for it is here.

Posted to modperl@perl.apache.org by yp...@club-internet.fr on 2006/03/10 18:31:47 UTC

Re: Modperl2 + PerlAccessHandler + Sending Cookie

I'm generating the cookie with CGI::Cookie().

I think the problem is elsewhere

>From a PerlResponseHandler, the method I described works,
but I got the problem within a PerlAccessHandler.

Should I delegate the cookie generation to the PerlResponseHandler ?

Younes


---Message d'origine----
>Date: Fri, 10 Mar 2006 09:04:58 -0800 (PST)
>Sujet: Re: Re: Modperl2 question
>De: "Fred Moyer" <fr...@taperfriendlymusic.org>
>A: yperl@club-internet.fr
>Copie à: modperl@perl.apache.org

>There's a few recipes here:
>http://perl.apache.org/docs/2.0/user/coding/cooking.html#Sending_Cookies_Using_libapreq2

>How are you generating $cookie. You'll likely want to add the cookie in
>any case, to update certain values or timestamps, I can't think of a case
>where I haven't done so. You may want to look at Apache2::AuthCookie
>which is a fully functional module to do exactly this


----Message d'origine----
>De: yperl@club-internet.fr
>A: yperl@club-internet.fr
>Sujet: Modperl2 + PerlAccessHandler + Sending Cookie
>Date: Fri, 10 Mar 2006 18:06:23 +0100
>
>Hi All!
>
>I'm wondering if there is a correct way to send a cookie in a PerlAccessHandler.
>
>I've tried something like:
>$r->headers_out->add('Set-Cookie' => $cookie);
>and even:
>$r->err_headers_out->add('Set-Cookie' => $cookie);
>
>whithout success
>
>I would like to send the cookie if it doesn't exists and 
>leave in the request if it already exists.
>
>Any idea?
>
>Thanks
>Younes
>

Re: Modperl2 + PerlAccessHandler + Sending Cookie

Posted by Fred Moyer <fr...@redhotpenguin.com>.

On Mon, 13 Mar 2006, Foo Ji-Haw wrote:

> Hello Fred,
>
> Ok, the 12 layers of Apache is as cool as the OSI layers. Let's say that in 
> my PerlAuthzHandler I verified the user via a cookie (given to the client

You will want to use a PerlAuthenHandler to authenticate the user.

> during login). It sounds like double work to retrieve the user details again 
> during the PerlResponseHandler phase (I have to do that to process the page

Cache the user details in $r->pnotes in your PerlAuthenHandler so that you 
do not have to retrieve the user details again.

> based on the user). Following the mailing list thread, is the only/ preferred 
> way to use the bucket brigade?

Re: Modperl2 + PerlAccessHandler + Sending Cookie

Posted by Foo Ji-Haw <jh...@extracktor.com>.

Hello Fred,

Ok, the 12 layers of Apache is as cool as the OSI layers. Let's say that 
in my PerlAuthzHandler I verified the user via a cookie (given to the 
client during login). It sounds like double work to retrieve the user 
details again during the PerlResponseHandler phase (I have to do that to 
process the page based on the user). Following the mailing list thread, 
is the only/ preferred way to use the bucket brigade?

Fred Moyer wrote:
> On Mon, 13 Mar 2006, Foo Ji-Haw wrote:
>> Wow, a little tangent to the topic here: I didn't know that you can 
>> do this
>> PerlResponseHandler Apache2::Const::OK
>> Is that 'legal'? It's interesting to know, but I wouldn't know of a 
>> practical use for this trick.
>
> Specifying a return code for a handler phase is perfectly legal.  I 
> first saw this technique used in 'PerlMapToStorageHandler 
> Apache2::Const::OK' to skip the request phase which maps the uri to a 
> location on disk, but you can use it with any phase.
>
>> Last question: is it a best practice to do the user and access 
>> authentication check at the PerlAccessHandler level? I like the idea 
>> (obviously I've not been trying this way). A single authentication 
>> module that can be used across various PerlResponseHandler. Easy to 
>> maintain and propogate.
>
> The PerlAccessHandler phase runs in the same phase of the request 
> cycle as Apache's mod_access module, and is meant to handle the 
> request based on IP and domain information.  In httpd.conf, you can 
> say 'Order Allow, Deny',
> 'Deny from 123.456.789.012', or you can use the PerlAccessHandler 
> phase and
> examine the request IP and accomplish the same functionality ( see
> http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAccessHandler). 
> It is best practice to do access checks.
>
> Best practice for user authentication is to use PerlAuthenHandler, and 
> best practice for user authorization is the PerlAuthzHandler.  This 
> way, you can modify the request, and return DECLINED, and Apaches 
> authen and authz modules can do additional checks on those phases of 
> the request.  Or you can do authen/authz only in the mod_perl phases 
> and return OK or UNAUTHORIZED and skip Apache's auth/authz modules.
>
> Each phase in this diagram - 
> http://perl.apache.org/docs/2.0/user/handlers/http.html#HTTP_Request_Cycle_Phases 
>
> - has a corresponding hook in Apache which runs after mod_perl if 
> DECLINED is returned.  This is one of mod_perl's greatest strengths.

Re: Modperl2 + PerlAccessHandler + Sending Cookie

Posted by Fred Moyer <fr...@redhotpenguin.com>.

On Mon, 13 Mar 2006, Foo Ji-Haw wrote:
> Wow, a little tangent to the topic here: I didn't know that you can do this
> PerlResponseHandler Apache2::Const::OK
> Is that 'legal'? It's interesting to know, but I wouldn't know of a practical 
> use for this trick.

Specifying a return code for a handler phase is perfectly legal.  I first 
saw this technique used in 'PerlMapToStorageHandler Apache2::Const::OK' to 
skip the request phase which maps the uri to a location on disk, but you 
can use it with any phase.

> Last question: is it a best practice to do the user and access authentication 
> check at the PerlAccessHandler level? I like the idea (obviously I've not 
> been trying this way). A single authentication module that can be used across 
> various PerlResponseHandler. Easy to maintain and propogate.

The PerlAccessHandler phase runs in the same phase of the request cycle as 
Apache's mod_access module, and is meant to handle the request based on IP 
and domain information.  In httpd.conf, you can say 'Order Allow, Deny',
'Deny from 123.456.789.012', or you can use the PerlAccessHandler phase and
examine the request IP and accomplish the same functionality ( see
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAccessHandler). 
It is best practice to do access checks.

Best practice for user authentication is to use PerlAuthenHandler, and 
best practice for user authorization is the PerlAuthzHandler.  This way, 
you can modify the request, and return DECLINED, and Apaches authen and 
authz modules can do additional checks on those phases of the request.  Or 
you can do authen/authz only in the mod_perl phases and return OK or 
UNAUTHORIZED and skip Apache's auth/authz modules.

Each phase in this diagram - 
http://perl.apache.org/docs/2.0/user/handlers/http.html#HTTP_Request_Cycle_Phases
- has a corresponding hook in Apache which runs after mod_perl if DECLINED 
is returned.  This is one of mod_perl's greatest strengths.