John Wittkoski wrote:
> Geoffrey Young wrote on 6/29/04, 6:28 PM:
> >
> > > OLD WAY: [broken]
> > > $obj->{USER_ID} = $r->user;
> > > $obj->{USER_PASS} = $I->get_basic_auth_pw;
> >
> > I'm not sure where you would have gotten this way from, but it is clearly
> > wrong - in both apache 1.3 and 2.0 it is ap_get_basic_auth_pw that
> > populates
> > $r->user (r->user in 2.0 and r->connection->user in 1.3).
> >
> > > NEW WAY: [fixed]
> > > $obj->{USER_PASS} = $r->get_basic_auth_pw;
> > > $obj->{USER_ID} = $r->user;
> >
> > yes, this has always been the correct way.
>
> Sorry, I know this thread is from a few weeks back, but I'm a little
> behind (as usual) and I wanted to ask for clarification.
no problem :)
>
> Isn't the ordering issue mentioned above only critical if you are coding
> your own authentication handler?
yes. that was the assumption I made.
> (I don't know why you'd call
> get_basic_auth_pw outside of an authentication handler, but you might
> need to call $r->user outside of one.)
exactly why I assumed we were talking about an authentication handler.
after authentication the user is authenticated, so there is generally no
reason why you would want the password again. I mean, I suppose you might,
but I can't see why if your application is designed well.
> If the current request was
> already handled by the built in Basic (or other basic password using)
> authentication handler, didn't that handler already call
> get_basic_auth_pw, so $r->user is populated for the remainder of that
> request?
yes, that's right.
>
> I ask because we have code that runs in a post-authentication phase that
> calls $r->user and it's always there, even for subrequests.
it would be, but only after _somebody_ calls get_basic_auth_pw().
>
> That being said, I did notice that a few of the Apache::Auth* modules
> (that use the Basic auth mechanism to get the password) use
> is_initial_req to short circuit the authentication phase for
> sub-requests before they call get_basic_auth_pw, resulting in $r->user
> not being populated for post-authentication phases of subrequests unless
> they call it themselves. (Under 2.0 that is, since under 1.3 this is
> masked by the clever bug you mention.)
yup. I've never been entirely convinced that short-circuiting
authentication in subrequests is a good idea. at first, people were
returning DECLINED, an idea that started someplace (I'm not sure where) but
that we propagated in the cookbook. after the cookbook was published I
realized that was most certainly a bad idea - if you DECLINED then mod_auth
will kick in, so in order to pass auth for the subrequest you would need an
AuthUserFile, as mod_auth has no such special subrequest handling.
some folks choose to return OK, which has the effect you mentioned, namely
that $r->user will not be set for subrequests (in 2.0 at least). I think I
said someplace in the cookbook that using $r->is_initial_req to shortcircuit
subrequest logic isn't for everyone, that you'll need to decide what works
for your application. clearly, if you rely on $r->user within those
subrequests you'll need to either skip the $r->is_initial_req logic, or
always look for $r->user in the main request. that is, something like
my $user = ($r->prev || $r)->user();
# or
my $user = $r->main->user();
HTH
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
