[Slashcode-development] Fwd: Slash::Apache::User on PerlAuthzhandler?

[Clifton W. <cli...@gm...>]

On 5/16/07, Faye Gibbins <fgi...@st...> wrote:
>
> Hi Cliff,
>
>   Yep this helps. I did some more testing with a stripped down set of
> scripts and this is what I've found out:
>
> * User opens up a brand new Firefox session with no cookies or history
> of any sort.
>
> * Request comes in to apache and the first relavent thing apache does is
> PerlAccessHandler. $r->user is undefined.
>
> * Then apache (which is setup to do Cosign (i.e. kerberos with cookies)
> calls its Authentication routines but does not call PerlAuthenHandler,
> ever (or at least I can't get it to)

Right. PerlAuthenHandler depends on there being an "AuthName",
"AuthType" and "require" directive in that configuration context. If
there isn't, then the handler isn't run.

>
> * At this point the users is taken to another URL, asked to enter their
> password etc. Then they are returned to the original URL /with/ a brand
> new encrypted authentication (Cosgin) cookie.
>
> * So Apache starts up again and the call reaches PerlAccessHandler which
> now has a defined $r->user.

Which is promising, because then stacked PerlAccessHandlers should work.

> * Again Apache doesn't call PerlAuthenHandler. But does its cosign stuff
> again but as we have a valid cookie it passes through OK and doesn't
> redirect.
>
> * Then we get to PerlAuthzHandler, which does get called and has a
> defined $r->user.

Ah! I thought PerlAuthzHandler was attached to PerlAuthenHandler. If
this isn't the case, then I was wrong in my previous email.

> I.e, in order
>
> PerlAccessHandler
> Apache Auth
> PerlAccessHandler
> PerlAuthzHandler

Well, yes -- however, according to an earlier paragraph, it's more like:

PerlAccessHandler
       (Slash may think we're anonymous but it doesn't matter
        since we...)
Redirect
Apache Auth
PerlAccessHandler
PerlAuthzHandler

> So the upshot of this is that I need to rely upon $r->user (and
> therefore REMOTE_USER).  And it seems to me (but I'm prepared to stand
> corrected) that the first time Slash::Apache::User gets called it looks
> to slash like we're anonymous.
>
> What I've not investigated yet is weather slash gives me a cookie at
> that point which says "I'm anonymous".

I'm not sure either, but if it does that cookie would be replaced by
the "I'm logged in cookie", otherwise there would be problems with
Slash. Moot point, I think. ^_^

> Which is why from MPOV it'd be better to either:
>
> 1) Move the whole shebang to PerlAuthzHandler, or
> 2) Leave the IP blocking stuff of Slash::Apache::User on the
> PerlAccessHandler and move every thing else to PerlAuthzHandler
>
> Either way instead of hacking my fix directly into Slash::Apache::User I
> might just put a hook into it and make things a bit more generic.

Well, you could do that. I'd prefer a stacked PerlAccessHandler
because it seems to be more straight forward and would involve less
work on your end. However if you'd feel better doing things this way,
you'd probably be better off *subclassing* Slash::Apache::User in a
PLUGIN (which is basically a Perl module) and changing things there
[you can then "use base qw(Slash::Apache::User)" and when you need to
use the old behavior just make a call to SUPER::

Or you could just rewrite the class entirely to your liking, and use
that class for your handlers instead of Slash::Apache::User and do
things as you like it. The options are numerous.

>   If I get to to work I'll submit a patch.
>

It's better that you do this in your own module first before worrying
about patching main Slash. Make sure you have something that works,
first.

Good luck, Faye!

- Cliff