【问题标题】：Azure Portal: Bad Request - Request Too LongAzure 门户：错误请求 - 请求太长
【发布时间】：2018-02-16 10:09:55
【问题描述】：

当我尝试从 portal.azure.com 运行 built-in b2c 编辑策略时，我刚刚收到以下错误。我打开了 2 个门户选项卡。为什么我会收到此错误？

错误请求 - 请求太长 HTTP 错误 400。请求标头的大小太长。

注意：我在测试active-directory-b2c-dotnet-webapp-and-webapi sample project 时遇到了this same error message。提供的原因是我发送了太多 cookie。是不是同样的问题？

如果是同样的问题，不应该在创建新问题之前将cookies be deleted 陈旧？

我确实看到了很多 https://login.microsoftonline.com 的 cookie

【问题讨论】：

http 400: size of header request is too long when signing in user using Multifactor authentication的可能重复

标签： azure-active-directory azure-ad-b2c azureportal

【解决方案1】：

问题是因为在多个租户和创建 cookie 的租户之间切换。我们确实经常面临这个问题。据我所知，唯一的解决方案是删除 cookie。

如果你是 chrome 爱好者，有一个编辑 cookie 扩展，使用它并尝试删除 login.microsoftonline.com 和 portal.azure.com 的 cookie

【讨论】：

虽然删除 cookie 通常对我有用，但我认为这不是对客户的合理期望，尤其是那些不精通 cookie 以及如何删除它们的客户。如果有人可以同时登录多个 Google 应用程序/服务（使用 SSO），为什么与 Microsoft 不同？
客户从未遇到过此类问题。只有我们开发人员会遇到这种情况，因为我们正在切换多个租户和多个租户策略。
实际上，仅本周我们就有几个客户遇到了这个问题。他们通过我们的客户应用程序使用 Office 365 + Azure AD B2C。
如果您的 cookie 实现处理发生变化，这当然也可能发生。例如，从单一到分块。如果用户有仍然有效的旧 cookie，他们会收到此错误。

【解决方案2】：

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

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

我还没有尝试过上面关于插件的方法，但会试一试，因为它比杀死所有浏览器窗口更流畅

【讨论】：

【解决方案3】：

错误HTTP 400: Size of header request is too long一般是因为cookie太多或cookie太大。

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

这对于开发人员来说肯定比最终用户更频繁地发生，因为开发人员使用他们的公司帐户登录到 Azure 门户，也可能使用 B2C 管理员帐户，然后通过多次登录测试他们的 B2C 驱动的应用程序。

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

但是，在此期间，您可以探索两件事：

清除您的 cookie。这肯定每次都能奏效，只是很麻烦，尤其是在呈现给最终用户时。
限制您在令牌中包含的声明数量。您include in your policy 的属性越多，您最终会收到更长的 http 请求，从而为来自其他 Microsoft 属性的 cookie 提供更少的余地

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

2018-11 更新：

Azure AD B2C 允许您使用use b2clogin.com 而不是 login.microsoftonline.com，这将大大减少您遇到此问题的风险，因为您将不再与其他 Microsoft 服务共享 cookie。

【讨论】：

由于这个错误，我们切换到使用tenantname.b2clogin.com，虽然它帮助了一段时间，但我们现在有用户在这个域上遇到同样的错误，所以我认为除非Microsoft 更改了他们的 cookie 管理方式，即使使用自定义域，此错误也会不断出现。
确保您没有忘记 #2 - 限制您包含在令牌中的声明数量。无论您发回的任何声明对某些用户来说都可能具有很大的价值。更好的做法是拥有一个超级修剪的标记并进行图形调用以检索您需要的任何属性。
我们有一个非常小的令牌。它似乎对我们没有帮助。令我震惊的是，像微软这样的国际公司正在兜售具有如此巨大缺陷的产品。 “不要登录太多，否则会崩溃”本质上是我必须给我们的一些服务用户的建议。
@Saca 我们在 b2clogin.com 域中也遇到了这个问题。使用自定义策略时，关于“#2 - 限制您包含在令牌中的索赔数量”，这很重要：令牌中的索赔数量、旅程中的索赔总数或存储在SSO 会话？

【解决方案4】：

如果您的 Azure 帐户遇到“HTTP 错误 400 错误请求 - 请求太长”，您可能还需要检查该 URL 是否已被微软更新。

就我而言，我想检查我的 Azure 订阅。我曾经访问过这个网址： https://account.azure.com/Subscriptions

但最近它开始给我“错误的请求标头太长”的问题。我检查了 URL，发现现在这是访问我的订阅的正确位置： https://account.windowsazure.com/Subscriptions

【讨论】：

【解决方案5】：

我收到了多个答案，这是因为我参与了太多 Active Directory。当我遇到这个问题时，我是零活动目录的一部分。在再次发生这种情况之前，我清除了我的 cookie 并走了大约两个步骤。该请求似乎在请求中发送了许多 microsoft cookie、azure cookie、facebook cookie、google cookie、adsense cookie 和linkedin cookie，但删除它们都没有帮助。我终于通过了隐身标签。

tl;dr 试试隐身标签

【讨论】：

【解决方案6】：

您可能还想查看 b2clogin.com 描述的 here。根据微软：

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

【讨论】：