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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx