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=

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

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

> 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 -