Nginx 反向代理 - 透传基本认证答案

【问题标题】：Nginx reverse proxy - passthrough basic authenicationNginx 反向代理 - 透传基本认证
【发布时间】：2013-01-28 04:22:19
【问题描述】：

我正在尝试将 nginx 设置为在几个使用基本身份验证进行身份验证的 IIS Web 服务器前面的反向 rpoxy 服务器。

（注意 - 这与 nginx providing the auth using a password file 不同 - 它应该只是在浏览器/服务器之间编组所有内容）

它的工作方式关闭 - 但页面上的每个资源（图像/css 等）都会反复提示进行身份验证。

upstream my_iis_server {
      server 192.168.1.10;
}

server {
    listen       1.1.1.1:80;
    server_name  www.example.com;  

    ## send request back to my iis server ##
    location / {
     proxy_pass  http://my_iis_server;
     proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
     proxy_http_version      1.1;
     proxy_set_header        Connection "";
     proxy_pass_header       Authorization;     
     proxy_redirect off;
     proxy_buffering off;
     proxy_set_header        Host            $host;
     proxy_set_header        X-Real-IP       $remote_addr;
     proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
   }
}

【问题讨论】：

标签： iis nginx basic-authentication reverse-proxy

【解决方案1】：

这个确切的情况让我花了很长时间才弄明白，但我猜 OSS 就是这样。这篇文章已经有一年了，所以可能是原发帖人想通了，还是放弃了？

无论如何，对我来说问题至少是由几件事引起的：

IIS 期望领域字符串与它发送到 Nginx 的字符串相同，但如果您的 Nginx server_name 侦听的地址与上游地址不同，则服务器端 WWW-Authenticate 不会是 IIS 所期望的，并且忽略它。
内置的标头模块不会清除其他 WWW-Authenticate 标头，尤其是有问题的 WWW-Authenticate: Negotiate。使用 headers-more 模块清除旧的标头，并添加您告诉它的任何内容。

在这之后，我终于能够通过 Nginx 推送 Sharepoint 2010。

感谢stackoverflow。

server {
    listen 80;
    server_name your.site.com;

    location / {
            proxy_http_version      1.1;
            proxy_pass_request_headers on;
            proxy_set_header        Host            $host;
            proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

            #proxy_pass_header      Authorization; //This didnt work for me
            more_set_input_headers  'Authorization: $http_authorization';

            proxy_set_header  Accept-Encoding  "";

            proxy_pass              https://sharepoint/;
            proxy_redirect          default;
            #This is what worked for me, but you need the headers-more mod
            more_set_headers        -s 401 'WWW-Authenticate: Basic realm="intranet.example.com"';
    }
}

【讨论】：

原发帖人确实放弃了，而是尝试了微软的 IIS 应用程序请求路由 (ARR)，它确实可以毫无问题地处理基本和 NTML 身份验证，但在一些 SharePoint 2013 的最小下载中引起了一些非常奇怪的问题我从未深入了解的战略 (MDS)。
也许这会有所帮助：serverfault.com/questions/230749/…
@matt 嗨，我需要传递诸如 username:password 之类的东西而不是 realm="etc" 这仍然有效吗？
more_set_input_headers more_set_headers 这些是什么？
@deathangel908 它们是来自 headers-more 模块 (github.com/openresty/headers-more-nginx-module) 的指令，可以使用 nginx 编译以添加更多功能。

【解决方案2】：

我在使用 nginx/1.10.3 时也有同样的症状。我有一个受基本身份验证保护的服务，并且 nginx 作为客户端和服务器之间的反向代理。要求是 nginx 会通过授权。

对服务器的第一个请求确实通过了 Authorization 标头。第二个请求只是阻止了这个标头，这意味着客户端每个会话只能发出一个请求。

这在某种程度上与 cookie 有关。如果我清除了浏览器 cookie，则循环重复。客户端能够进行身份验证，但仅针对第一个请求。关闭浏览器也有同样的效果。

我的解决方案是将上游服务器从 https 更改为 http，使用：

proxy_pass http://$upstream;

代替：

proxy_pass https://$upstream;

【讨论】：