我想知道是否有可能出现以下情况：
Nginx 处理请求并将其路由到某种身份验证应用程序，在该应用程序中解释和验证 cookie 和/或其他类型的安全标识符。该应用程序可能会对请求进行一些添加（附加经过身份验证的标头）。身份验证失败将返回 HTTP 401。
然后，Nginx 接收请求并将其路由到授权应用程序，该应用程序根据身份和 HTTP 动词（put、delete、get 等）以及相关 URL 确定参与者/代理/用户是否有权执行预期操作。例如，授权应用程序可能会通过附加另一个标头来稍微修改请求。授权失败将返回 403。
（对想要以某种方式参与请求的任意数量的服务进行清洗、冲洗、重复代理模式。）
最后，Nginx 将请求路由到实际的应用程序代码中，在其中检查请求并根据相关 URL 执行请求的操作，并且应用程序可以通过查看更改后的 HTTP 请求来捕获和理解用户的身份。
理想情况下，Nginx 可以原生地或使用插件来执行此操作。有什么想法吗？
我考虑过的替代方案是让 Nginx 将初始请求交给身份验证应用程序，然后让该应用程序将请求代理回 Nginx（无论是在同一个盒子还是另一个盒子上）。
我知道有许多应用程序框架（Django、RoR 等）可以“在过程中”完成很多这样的工作，但我试图使事情变得更加通用和自包含，不同的应用程序可以“挂钩” Nginx 的 HTTP 管道，然后参与、短路，甚至相应地修改请求。
如果 Nginx 不能做到这一点，是否有人知道其他 Web 服务器可以按照上述方式执行？
答案1
经过大量的挖掘之后，Nginx 确实支持扩展以实现上述场景的能力，但没有任何明确的“开箱即用”的东西可以利用。
最有前途的插件之一是 Lua 模块，它可以用很少的代码来实现这种场景，从而在请求处理管道中启用 HTTP 子请求： http://wiki.nginx.org/HttpLuaModule
另一个是俄罗斯 OpenStats.com 人员编写的自定义模块。此模块可能需要使用少量 C 代码进行定制： http://mdounin.ru/hg/ngx_http_auth_request_module/file/a29d74804ff1/README
最后是可以编写一个自定义模块，不基于前面提到的模块，但仍然直接连接到子请求： http://www.evanmiller.org/nginx-modules-guide.html