Maxim Dounin
April 24, 2013 06:38AM

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

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Maxim Dounin

nginx mailing list
Subject Author Posted

Feature extension to auth_request module: FastCGI authorizer

davidjb April 22, 2013 12:35AM

Re: Feature extension to auth_request module: FastCGI authorizer

Maxim Dounin April 22, 2013 12:40PM

Re: Feature extension to auth_request module: FastCGI authorizer

davidjb April 23, 2013 07:23PM

Re: Feature extension to auth_request module: FastCGI authorizer

Maxim Dounin April 24, 2013 06:38AM

Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 67
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready