指定重定向后，AAD身份验证之后的无限重定向循环 [英] Infinite re-direct loop after AAD Authentication when redirect is specified

问题描述

如果我像这样在我的OpenIdConnectAuthenticationOptions中指定重定向URI

If I specify a redirect URI in my OpenIdConnectAuthenticationOptions like so

app.UseOpenIdConnectAuthentication(
            new OpenIdConnectAuthenticationOptions
            {
                ClientId = clientId,
                Authority = Authority,
                PostLogoutRedirectUri = postLogoutRedirectUri,
                RedirectUri = redirectUri,

                Notifications = new OpenIdConnectAuthenticationNotifications()
                {
                    AuthenticationFailed = context =>
                    {
                        context.HandleResponse();
                        context.Response.Redirect("/Error?message=" + context.Exception.Message);
                        return Task.FromResult(0);
                    }
                }
            });

然后我得到一个无限的重定向循环.尽管仅当我将其放在独立的IIS服务器(我们的测试服务器)上时才会发生这种情况.如果我删除AAD中的所有重播URL，并仅将其保留为测试服务器的设置，然后删除"RedirectUri = redirectUri"，则上述问题消失了.

Then I get an infinite re-direct loop. This only happens though when i put it on and standalone IIS Server (our test server). If i remove all the Replay url's in AAD and leave it only setup for the test server, and remove the "RedirectUri = redirectUri," from the above my problem goes away.

我在这里有提琴手日志: https://drive. google.com/file/d/0B5Ap95E_wdyAa0RLLWloZ0dCaGM/view?usp=sharing

I have a fiddler log here : https://drive.google.com/file/d/0B5Ap95E_wdyAa0RLLWloZ0dCaGM/view?usp=sharing

看来，当AAD的请求返回到我的应用程序时，在获取和使用令牌之前，中间件只是用302将其弹回.同样重要的是，我具有[Authorize]属性通过路由和返回uri定向到的mvc控制器.如果我将其删除，则不会出现此问题.

It appears that when request from AAD comes back to my app, before the token is grabbed and used, the Middle Ware is just bouncing it right back with a 302. Also what may be important, I have the [Authorize] attribute over the mvc controller that the routing and return uri directs to. If I remove it i do not get this issue.

[更新] 我尝试将应用程序移动到我的IIS的本地安装中，而不是使用iisexpress，以便可以像在iis服务器上一样将其设置为SubApplication.在我的本地主机上，它执行相同的无限循环.我在[Authorize]属性的替代项上添加了一些遥测自定义事件，并且能够发现在身份验证httpContext.user.identity.IsAuthenticated = false后将页面重定向回应用程序时发现.那么以某种方式OWIN中间件没有将其设置为true吗?

[UPDATE] I tried moving the application to my localhost install of IIS rather than using iisexpress so that i could setup as a SubApplication like it is on my iis server. On my localhost it does the same infinite loop. I added in some telemetry custom events on an override of the [Authorize] attribute and have been able to discover that when page is re-directed back to the application after authentication httpContext.user.identity.IsAuthenticated = false. So somehow the OWIN middle ware is not setting this to true?

感谢您的帮助！

推荐答案

我能够找到解决问题的方法.最初，我指定的是回复网址，以指向网站的根目录.我的溃败配置看起来像这样:

I was able to find a solution to my problem. Originally i was specifying my reply url's to point to the root of the site. My rout config looks like this:

routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Welcome", action = "Index", id = UrlParameter.Optional }
        );

如果我在回复URL的末尾附加"Welcome(欢迎)"，则它可以正常工作.由于某种原因，如果我将回复URL保留到网站的根目录，并选择了默认路由，则会陷入无限循环.

If I append "Welcome" to the end of my reply url it works. For some reason if i leave the reply url to the root of the site and have the default route picked up it just goes into an infinite loop.

我还发现这仅适用于站点的子应用程序.我尝试将应用程序移动到iis中的独立站点，而不是，而不必在回复URL中添加控制器名称.

I found out also that this only applies to a sub application of a site. I tried moving my application to be a standalone site in iis so rather than and I didnt have to add the controller name in the reply url.

示例:
原始回复网址: mysite.mydomain.com/CustomApp

Example:
Original reply url: mysite.mydomain.com/CustomApp

新回复网址: mysite.mydomain.com/CustomApp/Welcome

New Reply url: mysite.mydomain.com/CustomApp/Welcome

希望其他人可以找到有用的东西！

Hope someone else can find this useful!

更新

我发现问题的根源仍然是由以下mvc5错误引起的:katanaproject.codeplex.com/workitem/197.我以为它已经修复，但是还没有修复，所以我将继续使用著名的Kentor Owin Cookie保护程序:github.com/Sustainsys/owin-cookie-saver

I found out that the root of the problem was still caused from this mvc5 bug: katanaproject.codeplex.com/workitem/197. I thought it had been fixed but it has not, so i will continue to use the well known Kentor Owin Cookie Saver: github.com/Sustainsys/owin-cookie-saver

这篇关于指定重定向后，AAD身份验证之后的无限重定向循环的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！