CORS预检请求在Azure托管的Web API中响应302重定向

Question

场景：

我有两个在Windows Azure上单独托管的ASP.NET Web应用程序，它们都与同一个Azure Active Directory租户相关联：

1. 带有AngularJS SPA前端的MVC应用程序和用于在客户端上处理Azure AD身份验证的adal.js库。

2. 带有Microsoft OWIN中间件的Web API，用于在服务器上处理Azure AD身份验证。

问题：

当角度引导客户端应用程序时，页面在通过oauth重定向到正确的Identity Authority后正确加载，并且adal.js库正确检索并存储每个应用程序的不同令牌（通过检查“资源/会话 - 存储”选项卡进行验证Chrome开发工具）。 但是当客户端应用程序尝试访问或更新API中的任何数据时，CORS预检请求正在响应302重定向到Identity Authority，这会导致控制台中出现以下错误：

XMLHttpRequest无法加载https://webapi.azurewebsites.net/api/items 。 请求被重定向到' https://login.windows.net/ {authority-guid} / oauth2 / authorize？response_type = id_token＆redirect_uri = .... etc..etc ..'，这对于跨源请求是不允许的这需要预检。

示例标头（匿名）：

Request
OPTIONS /api/items HTTP/1.1
Host: webapi.azurewebsites.net
Connection: keep-alive
Access-Control-Request-Method: GET
Access-Control-Request-Headers: accept, authorization
Origin: https://mvcapp.azurewebsites.net
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
Accept: */*
Referer: https://mvcapp.azurewebsites.net/

Response
HTTP/1.1 302 Found
Content-Length: 504
Location: https://login.windows.net/{authority-guid}/oauth2/authorize?response_type=id_token&redirect_uri=https%3A%2F%2F....etc..etc.%2F&client_id={api-guid}&scope=openid+profile+email&response_mode=form_post&state=...etc...
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Set-Cookie: ARRAffinity=4f51...snip....redact....db6d;Path=/;Domain=webapi.azurewebsites.net

我做了什么/尝试过

1. 确保Azure AD租户允许OAuth2隐式流，如此处和其他地方所述。
2. 确保API 公开访问权限 ，并且MVC / SPA使用这些公开的权限注册访问 。
3. 在API的web.config中明确添加了一个OPTIONS动词处理程序（见下文）。
4. 使用了在API服务器上启用CORS的各种组合，OWIN本身以及EnableCorsAttribute（见下文）。

问题

是否有任何方法可以使与Azure AD租户关联的Web API不重定向CORS预检请求？ 我在adal.js库中缺少一些初始化设置和/或OWIN启动代码（见下文）？ Azure门户中是否有允许OPTIONS请求通过OWIN管道的设置？

相关代码：

adal.js初始化

angular.module("myApp", ["ngRoute", "AdalAngular"])

.config(["$routeProvider", "$locationProvider", "$httpProvider", "adalAuthenticationServiceProvider",
    function ($routeProvider, $locationProvider, $httpProvider, adalProvider) {

        $routeProvider.when("/", { // other routes omitted for brevity
            templateUrl: "/content/views/home.html",
            requireADLogin: true // restrict to validated users in the Azure AD tenant
        });

        // CORS support (I've tried with and without this line)
        $httpProvider.defaults.withCredentials = true;

        adalProvider.init({
            tenant: "contoso.onmicrosoft.com",
            clientId: "11111111-aaaa-2222-bbbb-3333cccc4444", // Azure id of the web app
            endpoints: {
                // URL and Azure id of the web api
                "https://webapi.azurewebsites.net/": "99999999-zzzz-8888-yyyy-7777xxxx6666"
            }
        }, $httpProvider);
    }
]);

OWIN中间件初始化

public void ConfigureAuth(IAppBuilder app)
{
    // I've tried with and without the below line and also by passing
    // in a more restrictive and explicit custom CorsOptions object
    app.UseCors(CorsOptions.AllowAll);

    app.UseWindowsAzureActiveDirectoryBearerAuthentication(
        new WindowsAzureActiveDirectoryBearerAuthenticationOptions
        {
            TokenValidationParameters = new TokenValidationParameters
            {
                // Azure id of the Web API, also tried the client app id
                ValidAudience = "99999999-zzzz-8888-yyyy-7777xxxx6666"
            },
            Tenant = "contoso.onmicrosoft.com"
        }
    );

    // I've tried with and without this
    app.UseWebApi(GlobalConfiguration.Configuration);
}

WebApiConfig初始化

public static void Register(HttpConfiguration config)
{
    // I've tried with and without this and also using both this
    // and the OWIN CORS setup above. Decorating the ApiControllers
    // or specific Action methods with a similar EnableCors attribute
    // also doesn't work.
    var cors = new EnableCorsAttribute("https://mvcapp.azurewebsites.net", "*", "*")
    {
        cors.SupportsCredentials = true // tried with and without
    };
    config.EnableCors(cors);

    // Route registration and other initialization code removed
}

API OPTIONS动词处理程序注册

<system.webServer>
  <handlers>
    <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
    <remove name="OPTIONSVerbHandler" />
    <remove name="TRACEVerbHandler" />
    <add name="OPTIONSHandler" path="*" verb="OPTIONS" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" />
    <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
  </handlers>
</system.webServer>

相关资源

在某个时间，我已经尝试了以下（以及更多）论坛和博客文章以及github示例代码中的所有可以想象的组合。

1. ADAL JavaScript和AngularJS - Deep Dive
2. 使用Azure Active Directory，Owin Middleware和ADAL保护ASP.NET Web API 2
3. 使用ASP.NET Web API 2，Owin和Identity进行基于令牌的身份验证
4. AzureADSamples / SinglePageApp-DotNet（github）
5. AngularJSCORS（github）
6. 如何在WebAPI 2中进行CORS身份验证？
7. WebApi上的AngularJS和OWIN身份验证

Answer 1

我有类似的问题来找出适合的包。 只有Owin cors就足够了。请先检查一下owin.cors的软件包。

<package id="Microsoft.Owin" version="3.0.0" targetFramework="net45" />
<package id="Microsoft.Owin.Cors" version="2.1.0" targetFramework="net45" />

处理程序的WebConfig选项：

<system.webServer>
<handlers>
  <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
  <remove name="OPTIONSVerbHandler" />
  <remove name="TRACEVerbHandler" />
  <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>

你正在使用owin config中的specsiying cors选项做对了。

 public void ConfigureAuth(IAppBuilder app)
    {
        app.UseWindowsAzureActiveDirectoryBearerAuthentication(
            new WindowsAzureActiveDirectoryBearerAuthenticationOptions
            {
                Audience = ConfigurationManager.AppSettings["ida:Audience"],
                Tenant = ConfigurationManager.AppSettings["ida:Tenant"]

            });
        app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll);
    }

控制器不需要CORS相关属性。

   [Authorize]
public class ContactsController : ApiController
{

    // GET api/<controller>
    public IEnumerable<string> Get()
    {
        return new string[] { "person1", "person2" };
    }

    // GET api/<controller>/5
    public string Get(int id)
    {
        return "person" + id;
    }

WebAPIConfig不需要与CORS相关的条目。

工作示例如下： https ： //github.com/omercs/corsapisample

您可以使用以下代码在应用中进行测试：

app.factory('contactService', ['$http', function ($http) {
var serviceFactory = {};

var _getItems = function () {
    $http.defaults.useXDomain = true;
    delete $http.defaults.headers.common['X-Requested-With'];
    return $http.get('http://yourhostedpage/api/contacts');
};

serviceFactory.getItems = _getItems;

return serviceFactory;

}]）;

预检回应示例：

Remote Address:127.0.0.1:8888
Request URL:http://localhost:39725/api/contacts
Request Method:OPTIONS
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:accept, authorization
Access-Control-Request-Method:GET
Host:localhost:39725
Origin:http://localhost:49726
Proxy-Connection:keep-alive
Referer:http://localhost:49726/myspa.html
User-Agent:Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
Response Headersview source
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:authorization
Access-Control-Allow-Origin:http://localhost:49726
Content-Length:0
Date:Fri, 23 Jan 2015 01:10:54 GMT
Server:Microsoft-IIS/8.0
X-Powered-By:ASP.NET

Answer 2

解决了（有点）

这似乎是由部署问题引起的，特别是我最初将应用程序发布到Azure的方式。 这两个应用程序最初都是使用Windows身份验证编写的，并且已部署到标准（即非Azure）Web服务器。 使用这些技术，应用程序按预期工作。

根据新的业务需求，我一直在努力将它们迁移到Azure。 我遵循的过程是：

1. 将最初编写的两个应用程序从Visual Studio 2013发布向导直接部署/发布到Azure。 当然，正如预期的那样，这破坏了，因为它们无法与Azure内部的本地Active Directory通信。
2. 逐步更新代码以删除Windows身份验证并使用Azure AD身份验证替换问题末尾所有链接的详细信息。
3. 使用Azure AD门户将应用程序与Azure AD租户手动关联以进行身份​​验证。

在某些时候，我注意到VS Publish向导的Settings选项卡上的Enable Organizational Authentication选项，并开始使用它将应用程序与租户关联。 因为我已经手动关联它们，所以Visual Studio最终为每个创建了另一个Azure AD应用程序，从而产生了两个。

最后，这是做了什么：

1. 使用Portal删除了两个应用程序的所有Azure记录，包括Azure网站本身以及Azure AD站点/关联。
2. 将两个应用中的所有代码更改恢复为原始状态。
3. 在应用程序中重新实现Azure AD身份验证（OWIN，adal.js等）。
4. 两个应用程序的新发布是否让VS向导处理所有Azure关联。
5. 使用新创建的客户端ID更新了Web.config文件和adal.js初始化。
6. 再次发布。

现在，OPTIONS预检请求不再是302重定向。

相反，它们现在是405 Method Not Allowed，与此线程非常相似。 进步，一种。

即使它仍然没有端到端的工作，我会留下这个答案（而不是删除问题），以防它可能帮助其他人体验Azure 302重定向的CORS预检。