On Thu, 10 Jan 2008 13:48:26 +0100 Torsten Foertsch et> wrote:

> On Thu 10 Jan 2008, Vegard Vesterheim wrote:
>> The problem I encounter is that the authenticated user is not
>> propagated into to the subrequest, so my auth-handler can not do its
>> job. The following code is from Apache2::AuthCookie.pm:
>>
>> =C2=A0 =C2=A0 unless ($r->is_initial_req) {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (defined $r->prev) {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # we are in a subrequest. =C2=

=A0Just copy user from previous
>> request. =C2=A0 =C2=A0 $r->user( $r->prev->user );
>>
>> I observe that $r->is_initial_req is false (as it should be), but
>> $r->prev is undefined, so the authenticated user is not copied into
>> the request record. I have verified that the authenticated username
>> is available via $r->main->user.
>>
>> Why does $r->prev return undef in this case?
>>
>> Would it be ok to copy the autenticated username from $r->main->user
>> instead here?

>
> yes.
>
> is_initial_req() is literally the same as (!$r->main and !$r->prev), see=

=20
> server/request.c (httpd-source).
>
> If $r->main is set the current req is a subrequest generated by lookup_ur=

i()=20
> or lookup_file(). If $r->prev is set it is an internal redirect generated=

by=20
> internal_redirect() & co.


I see, so an internal redirect is a special case of a subrequest. I
have fixed my code to explicitly check for
$r->main->user and propagate the username into the running=20
subrequest. My problem is now solved. Thank you.

Whether a similar change should be made in modules like
Apache2::AuthCookie is still unclear to me. Is this to be considered a
bug? I guess the behaviour could be made configurable.

BTW, I find it useful to have auth-handlers also run during
subrequests, because I can use this to filter the display of links. If
a logged-in user will be refused access to a URL, I can suppress the
link in the first place. I can do this by calling lookup_uri behind
the scenes and checking the status code.

- Vegard V -