Azure门户：错误请求 - 请求过长。

Question

当我尝试从portal.azure.com运行内置的B2C编辑策略时，我收到了以下错误。我有2个门户标签页处于打开状态。为什么会出现这个错误？

Bad Request - Request Too Long HTTP Error 400. 请求头的大小太长。

注意：在测试active-directory-b2c-dotnet-webapp-and-webapi示例项目时，我遇到了相同的错误消息。提供的原因是发送了太多的cookie。这是同样的问题吗？

如果是同样的问题，那么在创建新的cookie之前，不应该清除旧的cookie过期吗？

---

我看到了很多关于https://login.microsoftonline.com的cookie。

- spottedmahn

---

可能是重复的问题：使用多因素身份验证签入用户时，HTTP 400：标头请求的大小太长 - spottedmahn

Answer 1

HTTP 400错误：请求头太长通常是由于太多的cookie或cookie太大导致的。

Azure AD B2C的登录通过login.microsoftonline.com进行，几乎所有Microsoft服务（O365、Azure等）都是如此。因此，如果您已经在这些服务中登录了多个帐户，那么您将累积会导致此问题的cookie。

开发人员比最终用户更容易遇到此问题，因为开发人员使用其公司帐户登录Azure门户，可能还使用B2C管理员帐户，并使用多个登录测试其基于B2C的应用程序。

从长远来看，答案将是是允许Azure AD B2C客户指定自己的自定义域。这使得应用程序的B2C cookie与login.microsoftonline.com中的其他内容隔离开来。截至2019-06-23，该功能仍在开发中。您可以在Azure AD B2C反馈论坛中投票支持此功能并跟踪其进展：客户拥有的域

然而，在过渡期间作为解决方法，有两件事情可以探索：

1. 清除浏览器cookies。这种方法每次都有效，但很麻烦，特别是对于最终用户而言。

2. 限制令牌中包含的声明数量。您在策略中包含的属性越多, 您将得到更长的http请求，这会给您留下更少的余地来使用其他Microsoft属性的cookies

注意：这与此问题相同：http 400: size of header request is too long when signing in user using Multifactor authentication

2018-11 更新：

Azure AD B2C允许您使用b2clogin.com而不是login.microsoftonline.com，这将大大减少您面临的问题，因为您将不再与其他Microsoft服务共享cookies。

2022-05 更新：

客户拥有的域名现已上线，已使用删除线更新答案。同时，修复了反馈链接。

- Saca

---

因为这个错误，我们改用tenantname.b2clogin.com。虽然一度有所帮助，但现在我们发现即使使用这个域名，用户仍然会遇到同样的错误。因此，我认为除非微软改变他们的cookie管理方式，否则即使使用自定义域名，这个错误也会不断出现。 - Chrift

确保您不要忘记第二点-限制令牌中包含的声明数量。您发送回来的任何声明可能对某些用户具有重要价值。更好的做法是拥有一个超级简化的令牌，并进行图形调用以检索所需的任何属性。 - Saca

我们拥有非常简单的令牌，但似乎没有帮助我们。作为一家国际公司，微软居然推销这样一个存在巨大缺陷的产品，我感到非常惊讶。“不要登录太多次，否则它会崩溃”基本上是我不得不给一些服务用户的建议。 - Chrift

@Saca，我们在使用b2clogin.com域时也遇到了这个问题。在使用自定义策略时，关于“＃2-限制包含在令牌中的声明数量”的问题，哪个是重要的：令牌中的声明数量，旅程中的总声明数量还是存储在SSO会话中的声明数量？ - sgdesmet

Answer 2

如果您在使用Azure帐户时遇到“HTTP错误400 Bad Request - Request Too Long”，您可能还需要检查Microsoft是否已更新URL。

在我的情况下，我想要检查我的Azure订阅。我曾经去过这个URL： https://account.azure.com/Subscriptions 但是最近它开始出现“Bad Request Headers Too long”的问题。 我检查了URL，并发现这是现在正确的访问我的订阅的位置： https://account.windowsazure.com/Subscriptions

- Phileo99

Answer 3

您可能还想查看在此描述的b2clogin.com。根据Microsoft的说法：

• Cookie不再与其他Microsoft服务共享。

- Joro G.

Answer 4

提醒一下：我在B2C团队工作，我们的人正在研究这个问题。这不是第一次出现，实际上，我们过去已经修复过它，所以可能是回归问题。我们将尽快报告更多信息。

- Jay Allen

Answer 5

问题是由于在多个租户之间切换并创建cookie导致的。我们经常遇到这个问题。据我所知，唯一的解决方案是删除cookie。

如果您是Chrome爱好者，可以使用编辑cookie扩展程序，并尝试删除login.microsoftonline.com和portal.azure.com的cookie。

- Ramakrishna

---

尽管删除Cookie通常对我有用，但我认为这不是一个合理的期望放在顾客身上，尤其是那些不熟悉Cookie及如何删除它们的顾客。如果有人可以同时登录许多谷歌应用/服务（使用SSO），为什么在使用微软时会有所不同呢？ - Rob Richardson

客户从来不会遇到这种问题。只有我们开发人员会遇到这种问题，因为我们要切换多个租户和多个租户策略。 - Ramakrishna

实际上，仅这个星期我们就有几位客户遇到了这个问题。他们正在通过我们的客户应用程序使用Office 365 + Azure AD B2C。 - Rob Richardson

这当然也可能发生，如果您的 cookie 实现处理发生了变化。例如，从单一到分块。如果用户有仍然有效的旧 cookie，则会收到此错误。 - JoeBrockhaus

Answer 6

我认为问题出在示例MVC应用程序中使用的默认OWIN实现上，唯一能做的就是关闭浏览器（和所有其他实例）并重新启动。

你可以看到cookie变得越来越大，最终浏览器放弃了。

我还没有尝试过关于插件的上述方法，但会尝试一下，因为它比关闭所有浏览器窗口更加顺畅。

- whatisthejava

Answer 7

我收到了多个答案，说这是因为我参加了太多的Active Directories。但实际上我在遇到这个问题时并没有参加任何Active Directory。我清除了我的cookies，然后进行了大约两步操作，但问题又出现了。请求似乎发送了许多微软cookies、Azure cookies、Facebook cookie、Google cookies、Adsense cookies和LinkedIn cookies，但删除它们都没有帮助。最终我使用了一个隐身标签页才成功通过。

简而言之，请尝试使用隐身标签页。

- Shane E.