我想知道是否有类似下面的情况：
Nginx处理一个请求并将其路由到某种authentication应用程序，在这个应用程序中解释和validationcookie和/或其他types的安全标识符。 该应用程序可能会添加一些附加的请求（追加validation头）。 失败的authentication返回一个HTTP 401。
然后Nginx接受请求并通过一个授权应用程序进行路由，授权应用程序根据身份和HTTP动词（put，delete，get等）和URL，确定actor / agent / user是否有权执行预期的行动。 例如，授权应用程序可能通过追加另一个标头来修改请求。 失败的授权返回403。
（清洗，冲洗，以任何方式重复代理模式，以便以某种方式参与请求。
最后，Nginx将请求路由到请求被检查的实际应用程序代码中，并根据所讨论的URL执行所请求的操作，并且通过查看被改变的HTTP请求，应用程序可以捕获和理解用户的身份。
理想情况下，Nginx可以在本地或通过插件来实现。 有任何想法吗？
我考虑过的另一种方法是让Nginx将初始请求交给authentication应用程序，然后让这个应用程序通过代理将请求返回给Nginx（无论是在同一个盒子还是另一个盒子上）。
我知道有很多应用程序框架（Django，RoR等）可以在进程中做很多这样的事情，但是我试图让事情变得更加通用和自包含在不同的应用程序可以“挂钩“Nginx的HTTPpipe道然后参与，短路，甚至相应地修改请求。
如果Nginx无法做到这一点，是否有人知道其他networking服务器将以上述方式执行？
在做了更多的挖掘之后，Nginx绝对支持扩展以实现上述场景的能力，但是没有任何明确的“开箱即用”可以使用。
最有前途的插件之一，可以使这个场景几乎没有代码将是Lua模块在请求处理pipe道中启用HTTP子请求： http : //wiki.nginx.org/HttpLuaModule
另一个在俄罗斯OpenStats.com家伙编写的自定义模块。 这个模块可能需要用一点C代码来定制： http : //mdounin.ru/hg/ngx_http_auth_request_module/file/a29d74804ff1/README
最后是写一个不是基于上述的自定义模块的可能性，但仍然直接挂钩到subrequests： http ://www.evanmiller.org/nginx-modules-guide.html