1

我正在使用 Azure 应用服务中的身份验证，也就是“简单身份验证” https://docs.microsoft.com/en-us/azure/app-service/app-service-authentication-overview

如果我使用它的 Azure 名称浏览我的 azure 网站，它工作正常：[myid].azurewebsites.net 但是如果将我的网站放在反向代理后面，在身份验证后，我总是被重定向到 [myid].azurewebsites。 net 而不是 www.[mydomain].com。反向代理已正确配置为为我的页面提供服务，并且无需身份验证即可正常工作。

我认为根本原因是“Easy Authentication”如何构建redirect_uri参数。使用 Chrome F12，我注意到在初始重定向到身份验证服务期间，浏览器 url 是使用 [myid].azurewebsites.net 而不是 www.[mydomain].com 构建的。

https://login.windows.net/034...51/oauth2/authorize?response_type=id_token&redirect_uri=https%3A%2F%2Fmyid.azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback& ..... .

我找不到指示/强制“简易身份验证”使用 www.[mydomain].com 的方法

有什么建议或想法吗？

--- 更新 ---
我使用 Nginx 作为反向代理。配置文件的相关片段（已编辑）：

server {
        server_name www.mydomain.com;
        listen 80;
        listen 443 ssl;
        ...
        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Real-Host $host;
                proxy_pass https://myid.azurewebsites.net/;
        }
}
4

2 回答 2

0

根据你的描述，我使用URL Rewrite和Azure Functions Proxies作为我的反向代理来测试这个问题，我发现我可能会遇到你提到的同样的问题。我也尝试比较Headers了通过反向代理访问和直接访问的<code>ServerVariables，并尝试覆盖相关的headers来缩小这个问题，但最终失败了。我假设由于我们使用的是内置应用服务身份验证/授权，因此我们无法覆盖redirect_uri参数的生成。

根据我的理解，您可以在反向代理下设置附加标头，然后在您的应用程序中构建身份验证/授权以获取附加标头以生成redirect_uri并将用户重定向到相关的授权端点。或者你可以使用负载均衡器的流量管理器，你可以关注这个问题。此外，如果您只想自定义您的 azure Web 应用程序域，您可以关注此处。

于 2017-12-19T06:40:42.707 回答
0

我们需要包含一个额外的参数来指示成功验证后进程应该重定向到的位置。我们可以使用 'post_login_redirect_uri' 参数来做到这一点。如果没有这个，该过程将重定向到默认的“身份验证成功”页面，其中包含返回该站点的链接。

有关更多详细信息，请参阅此文档：https ://weblogs.asp.net/pglavich/easy-auth-app-service-authentication-using-multiple-providers 。

于 2017-12-17T13:06:02.907 回答