httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sorin Manolache" <sor...@gmail.com>
Subject Re: Apache sub-requests
Date Fri, 29 Aug 2008 19:40:45 GMT
On Fri, Aug 29, 2008 at 20:52, Roy Wellington <deathanatos@gmail.com> wrote:
> I'm currently trying to port mod_auth_script, a Apache 1.x module that
> used the result of a script to allow/deny an authentication. The issue
> I'm currently running into is sub requests - it seems that whatever
> output and return code my module's sub request returns is what gets
> sent to the web browser. What should happen is:
> User asks for page.
> Module makes a sub request to script.
> Script returns a 200 OK, with a certain header set to allow or deny.
> Module either gives web browser either a 403 or the result of the
> original request.
>
> Currently I'm always getting 200 (even on bad credentials), and the
> returned document is the output of the script. (Just the body, not the
> headers.)
> I'm currently doing this as an AuthBasicProvider module. The following
> works, perfectly:
>
> static authn_status authn_check_password(request_rec *r, const char
> *user, const char *password)
> {
>        if(0 == strcmp("Joe", user)
>                && 0 == strcmp("bob", password))
>        {
>                return AUTH_GRANTED;
>        }
>        return AUTH_DENIED;
> }
>
> However, if I add these three lines at the top:
>        subreq = ap_sub_req_lookup_file("/path/to/script.php", r, NULL);
>        ret = ap_run_sub_req(subreq);
>        ap_destroy_sub_req(subreq);
>
> I get the odd behavior above. Just adding these three lines alone,
> should be essentially a no-op, aside from any side effects of having
> the php script invoked. But they're not. The ap_sub_req_lookup_file
> call returns 200, the ap_run_sub_req returns 0.
>
> Where am I going wrong with sub requests? How exactly do these work?
> The original mod_auth_script is here: http://mod-auth-script.sourceforge.net/


The behaviour you're describing is a "feature". It is designed to be
like that. The subrequest sends data to the client. By the time you
set the status of the main request to AUTH_DENIED the header line
"HTTP 200 OK" set by the subrequest is already gone to the client.

In order to avoid this, write a filter and add it after the
ap_sub_req_lookup_file(path, r, NULL) call.

In the filter, you parse the incoming bucket brigades (containing
(parts of) the response of the php script), but you never pass the
brigades down the filter chain. So in the filter, you simply pass the
output and return APR_SUCCESS or a failure, but don't do "return
ap_pass_brigade(f->next, bb). Thus, nothing is passed to the client at
the end of the subrequest execution.

S

Mime
View raw message