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

[<fgi...@st...>]

Hi,

  It turned out to be easier than I though to do what I wanted (with =20
CVS head as of a couple of weeks ago (start of May 2007)). I edited =20
the start of the handler in Slash::Apache::User (S::A::U) and added =20
this code:

snip---
sub handler {
=09my($r) =3D @_;

=09return DECLINED unless $r->is_main;

=09my $uri =3D $r->uri;

         # --new--
=09my $uid ;
=09{
=09    my $user =3D $r->user;
=09    my $slashdb =3D getCurrentDB();
=09    #print STDERR "User: ",$user,"\n";
=09    #print STDERR "UID: ",$slashdb->getUserUID($user),"\n";
=09    $uid =3D $slashdb->getUserUID($user);
=09    if(!$uid){
=09=09# create user;
=09=09my $matchname =3D nick2matchname($user);
=09=09#print STDERR "Matchname: $matchname\n";
=09=09$uid=3D$slashdb->createUser(
=09=09=09$matchname, $user."\@xxx.xx.ac.uk",$user);
=09=09$slashdb->sqlUpdate('users', {newpasswd =3D> "foobar"}, 'uid=3D'.$uid)=
;
=09    }
              my $newpass;
=09    ($uid,$newpass)=3DuserLogin($slashdb->getUserUID($user),"foobar");
=09    #print STDERR "UID: $uid\n";
=09    #print STDERR "NEWPASS: $newpass\n";
=09    $r->subprocess_env(SLASH_USER =3D> $uid);
=09}
         # --end of new--

snip---

About line 167 there's a "my $uid" which I've commented out.

Then I removed the login form from index.shtml and edited the =20
default:misc:mainmenu template to remove the change password link.

Then I edited apache's config to redirect any link for "login.pl" back =20
to the main page.

Works like a treat. It still needs some optimization and I'll want to =20
abstract it bit, but basically it works.

The one snag is that it doesn't log you in on the very first page, a =20
user needs to click on any link to get logged in. I need to find a way =20
to fake the cookie to fix this so I don't mess with the structure of =20
S::A::U too much.

Yours
Faye


Quoting Clifton Wood <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