我正在使用Azure应用服务中的身份验证，AKA“轻松身份验证” https://docs.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
如果我使用它的Azure名称浏览我的azure网站，它可以正常工作：[myid] .azurewebsites.net 但是如果将我的网站放在反向代理后面，在认证之后，我总是被重定向到[myid] .azurewebsites.net而不是www。[mydomain] .com。反向代理正确配置为我的页面提供服务，所有工作正常，无需身份验证。
我认为根本原因是redirect_uri参数是如何通过“Easy Authentication”构建的。使用Chrome F12我注意到在初始重定向到身份验证服务期间，浏览器网址是使用[myid] .azurewebsites.net而不是www。[mydomain] .com构建的。
我找不到指示/强制“轻松认证”使用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/;
}
}
答案 0 :(得分：0)
我们需要包含一个额外的参数来指示在成功验证后进程应该重定向到的位置。我们可以使用'post_login_redirect_uri'参数执行此操作。如果没有这个，该过程将重定向到默认的“身份验证成功”页面，其中包含返回站点的链接。
有关详细信息，请参阅此文档：https://weblogs.asp.net/pglavich/easy-auth-app-service-authentication-using-multiple-providers。
答案 1 :(得分：0)
根据您的说明，我使用URL Rewrite和Azure Functions Proxies作为我的反向代理来测试此问题，我发现我可能遇到与您提到的相同的问题。我还尝试在通过反向代理访问和直接访问之间比较Headers，ServerVariables，并尝试覆盖相关的标头以缩小此问题，但最终失败了。我假设由于我们使用的是内置App Service身份验证/授权，因此我们无法覆盖redirect_uri参数的生成。
根据我的理解，您可以在反向代理下设置其他标头，然后在应用程序中构建身份验证/授权，以获取用于生成redirect_uri的其他标头并将用户重定向到相关的授权端点。或者您可以将Traffic Manager用于Load Balancer，然后您可以按照此issue进行操作。此外，如果您只想自定义您的azure网络应用域，则可以关注here。