且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

ASP OpenID Connect:错误的请求,请求太长

更新时间:2021-12-01 00:23:34

在我们的系统上解决了Chrome"OpenID Connect:错误请求,请求时间过长"的问题. 但是现在Firefox正在循环播放../smh

Solved Chrome "OpenID Connect: Bad Request, request too long" on our system. But now Firefox is looping.. /smh

我有相同的错误,但是我的解决方案最终有所不同.我将通过Azure AD连接成功进行身份验证. Login.microsoft将重定向回我的应用程序.然后,该应用程序将重新弹回login.microsoft,它将在该处循环播放,直到结束,导致Bad Request Took To Long错误.然后我注意到该应用程序的OpenID.connect大约有39个cookie.如果我删除了它们,它将在重新加载时循环播放.如果删除它们并删除了login.microsoft cookie,我将重新启动并成功登录,但登录后会循环播放.在这里检查并进一步研究,我发现问题出在AccountController.cs文件中.似乎在登录页面之后,它将转到服务器的根目录,而不是应用程序的根目录.该服务器上有一些应用程序.默认设置为RedirectUri ="/",它转到服务器的根目录.该应用程序在那里不存在,因此它将循环返回.循环返回后,login.microsoft将再提供一个可用的cookie并发送回去,哈哈.我只需要将RedirectUri ="/"更改为RedirectUri ="/serverfolderpath"就可以了!

I had the same error but my solution ended up being different. I would authenticate via Azure AD connect successfully. Login.microsoft would redirect back to my app. The app would then bounce back to login.microsoft and it would loop there until it ended in the Bad Request Took To Long error. I then noticed I had around 39 cookies for OpenID.connect for the app. If I deleted them, it would loop on reload. If I deleted them and deleted the login.microsoft cookies, I was back to the start and login successful but loop after login. Checking here and researching further, I discovered the issue was in the AccountController.cs file. It seems that after the login page, it was going to the root of the server, not the root of the application. This server has a few applications on it. The default setting was RedirectUri = "/" which goes to the root of the server. The app doesnt exist there so it would loop back. After the loop back login.microsoft would give another okay cookie and send back, lol. I just needed to change the RedirectUri = "/" to RedirectUri = "/serverfolderpath" and it worked!!

AccountController.cs

AccountController.cs

     if (!Request.IsAuthenticated)
        {
            HttpContext.GetOwinContext().Authentication.Challenge(new AuthenticationProperties { RedirectUri = "/subFolderHere" },
                OpenIdConnectAuthenticationDefaults.AuthenticationType);
        }

我通过检查检查Web应用程序中的Azure身份验证"线索发现了这一点,因为在我看来问题似乎是该应用程序认为身份验证是错误的.事实是,它永远不会回到应用程序中.

I discovered this by checking into the clue "Check Azure Authentication in web application" as the issue seemed to me that the app was thinking authentication was false. The truth was it never got back to the app.

在Web应用程序中检查Azure身份验证