问题描述
我创建了一个由 OWIN 托管的 WebAPI 2.还有一个使用 API 并充当客户端的 Web 应用程序 (AngularJS).
I have created an OWIN hosted WebAPI 2. There's also a web app (AngularJS) that's using the API and acting as a client.
我已将 CORS 的必要代码添加到 Startup.cs，并将其托管在与客户端不同的端口上的本地 IIS 中，并确认它修复了 Cors 问题.
I've added the necessary code for the CORS to the Startup.cs, and hosted it in local IIS on a port different than the client and confirmed that it fixes the Cors issue.
然后，我将这两个应用程序都部署到了 Azure(我已将这两个应用程序作为 Web 应用程序放在 Azure 上，并且我还尝试将 OWIN 放入当前处于预览状态的 Azure API)但是 - 预检请求现在失败(否Access-Control-Allow-Origin 出现在响应中).
Then, I deployed both apps to Azure (I've put both on the Azure as Web App, and I also tried putting the OWIN to the Azure API that is currently in preview) but - the preflight request now fails (no Access-Control-Allow-Origin present in the response).
问:是否有一些我不知道的特定 Azure?为什么 OWIN 在部署时不提供此标头但它在 localhost 上工作?我在应用程序的 Azure 刀片设置的属性窗口中看不到任何限制.
Q: Is there some specific of Azure I'm not aware of? How come that OWIN isn't serving this header when deployed but it's working on localhost? I don't see any constraints in the properties window on Azure blades settings for the apps.
注意事项:
关于我正在使用的设置的一些细节:
About some specifics of the setup I'm using:
- 使用
Owin、WebAPI2、Ninject、SignalR - 在每个后续请求的标头中发布和提供自定义令牌，并使用自定义过滤器进行验证.
- 我现在尝试的 Cors 是
*
Startup.cs的相关部分:
The relevant part of Startup.cs:
public void Configuration(IAppBuilder appBuilder)
{
appBuilder.UseCors(CorsOptions.AllowAll);
HttpConfiguration config = new HttpConfiguration();
config.Formatters.JsonFormatter.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore;
//bind IClientsNotifier with method returning singleton instance of hub
var ninjectKernel = NinjectWebCommon.GetKernel();
ninjectKernel.Bind<MySignalRHub>().ToSelf().InSingletonScope();
ninjectKernel.Bind<QueryStringBearerAuthorizeAttribute>().ToSelf();
GlobalHost.DependencyResolver = new NinjectSignalRDependencyResolver(ninjectKernel);
appBuilder.Map(
"/signalr", map =>
{
map.UseCors(CorsOptions.AllowAll);
var hubConfiguration = new HubConfiguration();
map.RunSignalR(hubConfiguration);
});
config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
config.Formatters.Remove(config.Formatters.XmlFormatter);
config.Filters.Add(new NoCacheHeaderFilter()); //the IE9 fix for cache
var resolver = new NinjectDependencyResolver(NinjectWebCommon.GetKernel());
config.Filters.Add((System.Web.Http.Filters.IFilter)resolver.GetService(typeof(WebApiAuthenticationFilter)));
appBuilder.UseNinjectMiddleware(NinjectWebCommon.GetKernel);
appBuilder.UseNinjectWebApi(config);
}
此外，为了支持 OPTIONS HTTP 请求，我已经从 web.config 中注释掉了以下行(否则，它会抛出 HTTP 错误 405)
Additionally, I've commented out the following line from the web.config in order to support the OPTIONS HTTP request (otherwise, it was throwing HTTP error 405)
<system.webServer>
<handlers>
<!--<remove name="OPTIONSVerbHandler" />-->
...
推荐答案
最后我采用了更简单的方法 - 删除了 CORS 的所有代码处理，只需将标题放在 web.config:
In the end I went with easier way - removed all code-handling of CORS and simply put the headers in the web.config:
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="http://my-client-website.azurewebsites.net" />
<add name="Access-Control-Allow-Methods" value="*" />
<add name="Access-Control-Allow-Headers" value="accept, content-type, x-my-custom-header" />
<add name="Access-Control-Allow-Credentials" value="true" />
</customHeaders>
</httpProtocol>
...
(请注意，allow-origin 在 url 的末尾没有斜杠！)
(note that allow-origin doesn't have a slash at the end of the url!)
allow-credentials 部分是为了满足 SignalR，可能没有它也可以.
The allow-credentials part was to satisfy the SignalR, probably it could do without it.
如果有人找到编码方式不起作用的原因，我想知道！
If someone finds a reason as to why the coded way isn't working I'd like to know!
这篇关于在 Azure Web 应用/Azure API 上部署时缺少 CORS 标头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！