On Thu, 10 Jan 2008 13:48:26 +0100 Torsten Foertsch <[EMAIL PROTECTED]> 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:
>>
>> unless ($r->is_initial_req) {
>> if (defined $r->prev) {
>> # we are in a subrequest. Just copy user from previous
>> request. $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_uri()
> or lookup_file(). If $r->prev is set it is an internal redirect generated by
> 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
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 -
