I’m currently looking to extend the ‘Auth Request’
(ngx_http_auth_request_module: log) Nginx add-on module
and
have the module be able to conform (at least wherever possible) to the
FastCGI “Authorizer” specification. The full specification is at
http://www.fastcgi.com/drupal/node/22#S6.3 - the idea being the
configured
authorizer should be hit with a sub-request, and if a 200 is returned,
then
access allowed, with some manipulation of special headers. This is fine
and
I’ve successfully written extended the existing auth-request code.
However, for any other response aside from 200, the Authorizer
specification
states that the server must send the response status, headers, and
content
back to the HTTP client. In my specific FastCGI authorizer, it sends
various
301/302 redirects to do single sign on. This is where I’ve gotten
stuck.
So far, within the ngx_http_auth_request_handler function, I’ve managed
to
have this mostly working using this:
ngx_http_request_t *sr;
...
if (authorizer) {
sr = ctx->subrequest;
r->headers_out = sr->headers_out;
return ctx->status;
}
which results in sending the subrequest’s headers and status back to the
client. I’m unsure if this is sensible in replacing headers in this
fashion
- eg performance or memory wise - so could some please comment on this?
It
does work though.
However, all that said, the subrequest’s response body is the missing
piece
of the puzzle. I did figure out that the sr above defaults to
sr->header_only = 1, so it is ignoring the response body. However,
turning this off results in the subrequest returning the body response
to
the client before main response headers can be sent – exactly as per
the
discussion here: Re: Making http_auth_request_module a first-class citizen? [patch] .
Curiously, only the sub-request response body is sent to the client, not
the
headers as well. If this behaviour for the subrequest could be changed
to
send its headers as well, then this would solve my problem.
One way or another, I’d like to get the subrequest’s response to the
client
as the whole response. Is this possible, and if so, how?
Thanks in advance!
– David
Posted at Nginx Forum:
Hello!
On Thu, Apr 18, 2013 at 12:55:16AM -0400, davidjb wrote:
states that the server must send the response status, headers, and content
r->headers_out = sr->headers_out;
return ctx->status;
}
which results in sending the subrequest’s headers and status back to the
client. I’m unsure if this is sensible in replacing headers in this fashion
- eg performance or memory wise - so could some please comment on this? It
does work though.
While this might work, I wouldn’t recommend relying on it. This
way headers are processed within subrequest context, and then
again within main request context. This might potentially result
in headers being not in sync with filter module contexts,
resulting in invalid response. Safer aproach would be to copy
only specific headers.
(On the other hand, I don’t think anything bad would happen with
standard filter modules, as most of them just ignore subrequests.)
One way or another, I’d like to get the subrequest’s response to the client
as the whole response. Is this possible, and if so, how?
What you are trying to do should be possible with
NGX_HTTP_SUBREQUEST_IN_MEMORY - this way subrequest body will be
available in memory instead of being sent to a client. But it’s
not currently supported for fastcgi.
–
Maxim D.
http://nginx.org/en/donation.html
Maxim D. Wrote:
What you are trying to do should be possible with
NGX_HTTP_SUBREQUEST_IN_MEMORY - this way subrequest body will be
available in memory instead of being sent to a client. But it’s
not currently supported for fastcgi.
Thanks for the clarification and your reply. I’ve taken to ignoring
request
and response bodies for now since in my use case, the auth_request
backend
really only needs to respond with redirections for Single Sign On.
Is the thinking that this may eventually be supported by other modules
like
FastCGI/uWSGI or is it related to some technical issue?
Thanks,
David
Posted at Nginx Forum:
Hello!
On Mon, Apr 22, 2013 at 12:17:31AM -0400, davidjb wrote:
really only needs to respond with redirections for Single Sign On.
Is the thinking that this may eventually be supported by other modules like
FastCGI/uWSGI or is it related to some technical issue?
The subrequest in memory functionality needs unbuffered handling
in the upstream module, which is not implemented for FastCGI.
–
Maxim D.
http://nginx.org/en/donation.html