我目前使用 nginx 作为代理,为后端数据库服务提供连接池,该服务在连接上使用基本 HTTP 身份验证:
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 10000;
}
http {
client_max_body_size 0;
sendfile on;
upstream cloudant_backend {
server <hostname>.cloudant.com:443;
keepalive 64;
}
server {
listen 5984;
server_name localhost;
location / {
proxy_pass https://cloudant_backend;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host <hostname>.cloudant.com;
proxy_set_header Authorization "Basic <base64encodedusernamepassword>";
}
}
}
nginx.conf 的原始来源:https://github.com/greenmangaming/cloudant-nginx
但是,有 more efficient option通过对
/_session
执行 HTTP POST 与后端进行身份验证端点以检索在后续请求中重用的身份验证 cookie。问题 : 使用 nginx 或 Apache httpd 可以吗?如果是这样,怎么做?
最佳答案
一种可能的解决方案可能如下所示:
Set-Cookie
header ,并将其值以 nginx 配置格式存储到文件中。配置将专用变量设置为 cookie 值。 proxy_set_header Cookie $auth_cookie;
更新 cookie 后,身份验证程序应发送 HUP信号使其重新加载配置。
另一个可能需要详细说明的问题/任务是如何在 session 意外到期的情况下使用react(例如,由于 cloudant 服务器重新加载)。为了解决它,我会设置一个简单的 FastCGI 像 this ,这将触发身份验证程序的计划外运行,然后将此 CGI 设置为 [下一个上游代理]。可能 CGI 还应该执行原始请求,以使整个执行链对您的服务器客户端完全透明。
自动续订的另一个问题是可能的竞争条件,当客户端向您的服务器发送请求而它不是有效的身份验证 cookie 时。现在对我来说似乎不可避免的是,CGI 必须实现某种锁定(对生成的配置文件或主 nginx 配置文件进行文件锁定?还不确定)以防止同时多次获取 cookie。
建议的方法将允许您构建整个解决方案,而无需更改 nginx 源本身。或者,如果您不介意编写 nginx 模块,则可以将解决方案移动到自定义模块中,但肯定需要更加小心地开发和调试它。
提议的解决方案的代码很简单,但如果您对特定部分有疑问,我可以提供一些示例和代码片段。
关于apache - 具有使用自定义 session 端点的连接池的反向代理?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27619654/