在Azure网站中启用Access-Control-Allow-Credentials标头(Azure App Services)

Max*_*ini 11 ajax azure cors azure-web-sites

我们最近将一个API应用程序从Azure云服务迁移到Azure网站,一些客户端仍在使用我们的旧协议进行身份验证,该协议使用cookie(而不是通常的Authorization: BearerHTTP标头).我们需要支持此身份验证协议一段时间,因为客户端无法立即迁移.

为了支持针对API的跨源ajax请求中的cookie,客户端需要将设置withCredentials设置为trueXMLHttpRequest,并且服务器需要使用Access-Control-Allow-Credentials标头以及任何CORS请求进行响应.

我们面临的问题是Azure网站自己管理CORS,并使用自己的配置(限于允许的来源列表)作为响应,这不允许设置此标头...从而打破了申请我们所有的Ajax客户端!

有没有办法(临时)在响应中添加此标头?

Max*_*ini 18

我们终于设法了解Azure Apps CORS中间件的行为.要禁用它,您必须清除Web应用程序(包括*)的CORS刀片中的每个允许的原始条目.然后,您可以自己管理CORS,使用Web Api 2功能或使用web.config.

这些信息甚至可以在文档中找到:

不要尝试在一个API应用程序中同时使用Web API CORS和App Service CORS.App Service CORS优先,Web API CORS不起作用.例如,如果在App Service中启用一个源域,并在Web API代码中启用所有源域,则Azure API应用程序将仅接受来自您在Azure中指定的域的调用.

因此,最终的答案是:如果您的应用程序不需要非常具体的CORS管理,则可以使用Azure App Service CORS.否则,您需要自己处理它并禁用Web应用程序中的所有CORS配置.

  • 奇怪的是,它应该有一个开关来禁用 Azure cors,只需删除所有站点即可禁用它并传递到您的应用程序。如果列出了任何来源,它似乎会删除您拥有的任何其他 CORS 标头(包括凭据、方法等)。我认为应该提供某种解释,即进入一个站点将启用它以及它将用于那些其他标头的值。我认为它也应该给出某种错误或警告来自动删除您的标题...... (2认同)

Con*_*hon 5

Azure 应用服务 CORS 功能现在支持此功能。不幸的是,它还没有用户体验,所以启用起来有点痛苦。目前有两种简单的方法。

  1. 在 Azure 门户上,导航到您的 Web 应用程序。导航到 API > CORS。现在有一个复选框Enable Access-Control-Allow-Credentials。选中此框并按Save

  2. 通过以下命令使用 Azure CLI:

az resource update --name web --resource-group myResourceGroup --namespace Microsoft.Web --resource-type config --parent sites/<app_name> --set properties.cors.supportCredentials=true --api-version 2015-06-01

您可以在此处查看更多文档。

注意:这不适用于*允许的来源。这是我们决定做出的安全选择。