Feature extension to auth_request module: FastCGI authorizer

[Maxim Dounin]

Hello!

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

> > 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 
nginx core:

   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#variables

-- 
Maxim Dounin
http://nginx.org/en/donation.html