Feature extension to auth_request module: FastCGI authorizer
mdounin at mdounin.ru
Wed Apr 24 10:37:55 UTC 2013
On Tue, Apr 23, 2013 at 07:23:26PM -0400, davidjb wrote:
> Maxim Dounin Wrote:
> > For me it doesn't looks like what you do actually matches FastCGI
> > Authorizer specification. Even if we ignore the fact that body
> > isn't handled properly, and authorizer mode isn't advertized to
> > FastCGI.
> > Most of the code in the patch seems to be dedicated to special
> > processing of Variable-* headers. But they don't seem to do what
> > they are expected to do as per FastCGI spec - with your code the
> > "Variable-AUTH_METHOD" header returned by an authorizer will
> > result in "AUTH_METHOD" header being passed to the application,
> > i.e. it will be available in HTTP_AUTH_METHOD variable in
> > subsequent FastCGI requests - instead of AUTH_METHOD variable as
> > per FastCGI spec.
> It's still very much a work in progress (fwiw, I started using Nginx last
> week). On another read of the FastCGI specification, I do agree that your
> interpretation is right - I was interpreting part of the specification
> without understanding the rest of the definitions. So, in that regard it
> could certainly be improved.
> However, if strictly adhering to the FastCGI spec, this would thus force the
> backend application to be FastCGI as well -- and this is why my code does
> what it does. The authorisation technology (Shibboleth) I'm working with
> needs to inject user-related variables into the request going to a backend
> application, and for ease of use/performance, I don't want to have to
> re-route via a FastCGI application.
> So perhaps on balance, this functionality may well be better suited to its
> own add-on module.
Note that if you just need to pass some variables you know about -
it can be easily done with auth_request_set and fastcgi_param
> > Please also note that it's bad idea to try to modify input headers -
> > this is not something expected to be done by modules, and will
> > result in a segmentation fault if you'll try to do it in a
> > subrequest.
> Okay, but what of a module like "Headers more" -- which allows you to
> manipulate any headers, incoming or outgoing. Should something like this
> not exist for Nginx or is it just considered 'bad practice'? Either way,
> I'd be curious for both the code I've written, and also as I'm relying on
> the "Headers more" module to drop certain request headers.
This is considered bad and unsupported by nginx core. You may
take a look at headers more module for a number of quirks it uses
for this to work.
Recommended aproach is to use variables and appropriate backend
protocol module directives (proxy_set_header, fastcgi_param, ...)
to pass them to a backend. An example of similar functionality in
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
More information about the nginx