ASP OpenID Connect:错误的请求，请求太长 [英] ASP OpenID Connect: Bad Request, request too long
问题描述
对于使用OpenID Connect进行Azure身份验证的网站，有时会收到错误请求-请求时间过长"的消息.请求标头的大小太长".现在，此问题发生在Google Chrome MF和Edge上.删除Cookie后，该站点将工作一个会话.重新启动浏览器后，问题再次出现.我正在运行4.0.0版的OpenID Connect软件包.
For a website which uses OpenID Connect to authenticate to Azure, I got sometimes the message 'Bad request - Request too long. the size of the request headers is too long'. The issue now occurs on Google Chrome MF and Edge. After deleting the cookies, the site will work for one session. On restart of the browser the problem returns. I'm running version 4.0.0 of the OpenID Connect package.
该问题是已知的，并且是由openid connect创建的随机数cookie引起的.当显示错误时，此时，浏览器(Chrome，Firefox和Edge)中存在超过20个此类cookie.我尝试了不同的方法，但仍然没有解决方案.
The issue is known and caused by the nonce cookies which are created by openid connect. When it shows the error, at that moment, more than 20 of those cookies exist in the browser (Chrome, Firefox and Edge). I tried different things, but still no solution.
- @ andrew.fox在并没有改变.
- 将该软件包降级到3.0.0版并没有解决它.较新版本的相关软件包会带来额外的问题.
- 按照 https://github.com/IdentityServer/IdentityServer3/中的建议删除旧的Nonce Cookie issue/1124 只能陷入删除和创建Cookie的无限循环.
- The answer from @andrew.fox at Too many cookies OpenIdConnect.nonce cause error page "Bad Request - Request Too Long" did not change a thing.
- Downgrading the package to version 3.0.0 didn't solved it eiter. Extra problems due to related package which were on newer versions.
- Deleting old Nonce cookies as suggested in https://github.com/IdentityServer/IdentityServer3/issues/1124 only ends up in an infinite loop of deleting and creating cookies.
编辑
将OpenIDConnect软件包降级到3.0.0版时，首次打开浏览器(在IIS中设置发布的代码之后)登录成功，并且登录到正确的页面.关闭并重新打开浏览器时(当用户仍处于登录状态时)，由于登录User.Identity.IsAuthenticated始终为false，因此即使登录成功也将在登录时开始无限循环.
When downgrading the OpenIDConnect package to version 3.0.0, the first time I open the browser (after setting published code in IIS) login is succeeded and it forwards to the correct page. When closing and reopening the browser (when user was still logged in) an infinite loop starts at login because the User.Identity.IsAuthenticated is always false even after a successful login.
推荐答案
在我们的系统上解决了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.
这篇关于ASP OpenID Connect:错误的请求，请求太长的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
