> -----Original Message-----
> From: will trillich [mailto:[EMAIL PROTECTED]]
>
> thanks one and all for the pointers on cookies. i probably grok
> 738% more than i did, but i have a feeling it's still only 13% of
> the pie. or in this case, cookie...
>
> so how's this PerlAccessHandler, for twisted logic? hole-punching
> and pitfall-warning equally welcome:
This ought to work fine, but it probably won't scale well if you ever have a
need to extend this to support multiple authentication paths (more than one
user database or user type). You'll just end up pushing more and more logic
into the handler which is going to get you into trouble. This won't scale
at all if you ever need to create a central login/ticket server.
The beauty of the example in the Eagle book (and Apache::AuthTicket) is that
it defines distinct handlers for distinct URL spaces which, in turn,
correspond to distinct functions (prompt for login, authentication,
authorization). If you ever have the need to separate these across multiple
servers, you'll have difficulties with your scheme.
Also, you'll always have to be extremely careful when extending this in the
future to always unshift login or authentication handlers when you return OK
or DECLINED. Since you've lumped login prompt/authentication/authorization
all into a single handler, returning OK without a challenge/authentication
handler will immediately grant access to the requested resource.
>
> #httpd.conf
> PerlAccessHandler My::TrollUnderTheBridge
> PerlHandler Something::OrOther
>
> #perl
> package My::TrollUnderTheBridge;
>
> sub handler {
> my $r = shift;
>
> if ( &logging_in($r) ) {
>
> my $h = $r->get_handlers( 'PerlHandler' );
> unshift @{$h},\&checkUser ; # do
> &checkUser first
> $r->set_handlers( PerlHandler => $h );
I think this is wrong. checkUser() should be a PerlAccessHandler. You
should probably simply return &checkUser rather than waiting until the
content handler phase.
>
> } elsif ( &needs_login($r) ) {
>
> $r->set_handlers( PerlHandler => [ \&login ] );
> # return AUTH_REQUIRED; or not ?
Not. Can only return OK, DECLINED or FORBIDDEN in a PerlAccessHandler.
Besides AUTH_REQUIRED (in a PerlAuthHandler) will prompt for a HTTP basic
authentication session, which you certainly don't want. Should simply
return OK or DECLINED and let the request fall through to the PerlHandler.
>
> }
>
> return OK;
> }
>
> sub checkUser {
> my $r = shift;
> if ( &bad_passwd( $r ) ) {
> # generate html for username/password
> login screen, again
> &login( $r );
> # we handled it, other handlers won't
> be called (right?)
> return OK;
> } else {
> $r->headers_out->add( 'Set-Cookie' =>
> &make_ticket( $r ) );
> # let normal handler do its thing
> return DECLINED;
> }
> }
>
> so i can keep the same url for all three stages, with no need for
> preliminary cookies:
>
> 3. valid ticket -> show web pages
> else
> 2. validate user/pass -> make ticket & show pages
> else
> 1. login -> get user/pass
>
> is this sound? or am i fuxnored?
>
> --
>
> but then from within &login() i'd like to be able to abort, like
> so--
>
