# Feature extension to auth\_request module: FastCGI authorizer **URL:** \ **Category:** NGINX\ **Created:** [April 22, 2013, 6:36am UTC](https://www.ruby-forum.com/t/feature-extension-to-auth-request-module-fastcgi-authorizer/228420 "2013-04-22T06:36:21Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![davidjb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/8e7dd6/32.png) [@davidjb](https://www.ruby-forum.com/u/davidjb)\ **Post date:** [April 22, 2013, 6:36am UTC](https://www.ruby-forum.com/t/feature-extension-to-auth-request-module-fastcgi-authorizer/228420/1 "2013-04-22T06:36:21Z")
I’ve written an additional feature into the Auth Request module (from [ngx\_http\_auth\_request\_module: log](http://mdounin.ru/hg/ngx_http_auth_request_module/)) that allows a user to control the behaviour of the auth\_request in such a way that it can act as a FastCGI authorizer. This patch that I have written allows the user to specify the flag “authorizer=on” against a call to “auth\_request” (eg “auth\_request /my-auth authorizer=on;”) and the auth request module will behave as per the authorizer specification ([http://www.fastcgi.com/drupal/node/22#S6.3](http://www.fastcgi.com/drupal/node/22#S6.3)). There is one (potentially significant) caveat for now is that request/response bodies are not passed to the authorizer or back to the client respectively - assistance on this would be greatly appreciated. However, as it stands at present, the authorizer mode is able to correctly handle situations where only the headers are utilised – eg the Shibboleth SSO FastCGI authorizer which relies on redirection and cookies and never a response/request body. This satisfies at least what I need it for at present and authentication works successfully. I’d like to see about whether this can be included within the main module itself at [ngx\_http\_auth\_request\_module: log](http://mdounin.ru/hg/ngx_http_auth_request_module), as I know this will be useful to more than just me. For example, see the various posts and questions surrounding this: [fastcgi authorizer nginx - Google Search](https://www.google.com/search?q=fastcgi+authorizer+nginx) . The latest version of my module lives at: [https://bitbucket.org/davidjb/ngx\_http\_auth\_request\_module](https://bitbucket.org/davidjb/ngx_http_auth_request_module) and the one main diff is located at: [https://bitbucket.org/davidjb/ngx\_http\_auth\_request\_module/commits/3d865a718d3e34e4e353962ccc71c588a806db31/raw/](https://bitbucket.org/davidjb/ngx_http_auth_request_module/commits/3d865a718d3e34e4e353962ccc71c588a806db31/raw/) Comments are more than welcome. Thanks, David Posted at Nginx Forum: > **[Feature extension to auth\_request module: FastCGI authorizer](https://forum.nginx.org/read.php?2,238523,238523#msg-238523)** > > I've written an additional feature into the Auth Request module (from http://mdounin.ru/hg/ngx\_http\_auth\_request\_module/) that allows a user to control the behaviour of the auth\_request in such a way that it can act as a FastCGI authorizer. This... ---
**Author:** ![davidjb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/8e7dd6/32.png) [@davidjb](https://www.ruby-forum.com/u/davidjb)\ **Post date:** [April 22, 2013, 6:39pm UTC](https://www.ruby-forum.com/t/feature-extension-to-auth-request-module-fastcgi-authorizer/228420/2 "2013-04-22T18:39:40Z")
Hello! On Mon, Apr 22, 2013 at 12:35:51AM -0400, davidjb wrote: > request/response bodies are not passed to the authorizer or back to the > questions surrounding this: > [Google Search](https://www.google.com/search?q=fastcgi+authorizer+nginx) . > > The latest version of my module lives at: > [https://bitbucket.org/davidjb/ngx\_http\_auth\_request\_module](https://bitbucket.org/davidjb/ngx_http_auth_request_module) > > and the one main diff is located at: [https://bitbucket.org/davidjb/ngx\_http\_auth\_request\_module/commits/3d865a718d3e34e4e353962ccc71c588a806db31/raw/](https://bitbucket.org/davidjb/ngx_http_auth_request_module/commits/3d865a718d3e34e4e353962ccc71c588a806db31/raw/) > Comments are more than welcome. 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. 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. – Maxim D. > **[nginx: donation](http://nginx.org/en/donation.html)** ---
**Author:** ![davidjb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/8e7dd6/32.png) [@davidjb](https://www.ruby-forum.com/u/davidjb)\ **Post date:** [April 24, 2013, 1:24am UTC](https://www.ruby-forum.com/t/feature-extension-to-auth-request-module-fastcgi-authorizer/228420/3 "2013-04-24T01:24:03Z")
## Maxim D. Wrote: > 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. > 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. As for the code I’ve written, the input headers are being modified after the subrequest has been completed, and this appears to succeed. So no seg faults so far. Posted at Nginx Forum: [http://forum.nginx.org/read.php?2,238523,238591#msg-238591](http://forum.nginx.org/read.php?2,238523,238591#msg-238591) ---
**Author:** ![davidjb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/8e7dd6/32.png) [@davidjb](https://www.ruby-forum.com/u/davidjb)\ **Post date:** [April 24, 2013, 12:38pm UTC](https://www.ruby-forum.com/t/feature-extension-to-auth-request-module-fastcgi-authorizer/228420/4 "2013-04-24T12:38:16Z")
Hello! On Tue, Apr 23, 2013 at 07:23:26PM -0400, davidjb wrote: > > “Variable-AUTH\_METHOD” header returned by an authorizer will > > 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; > **[Module ngx\_http\_proxy\_module](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header)** > > The ngx\_http\_proxy\_module module allows passing requests to another server. > **[Module ngx\_http\_proxy\_module](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#variables)** > > The ngx\_http\_proxy\_module module allows passing requests to another server. – Maxim D. > **[nginx: donation](http://nginx.org/en/donation.html)**