解决dotnet-webapi-starter-kit中的CORS跨域问题

在开发基于dotnet-webapi-starter-kit的项目时，部署到IIS后遇到了一个典型的CORS跨域资源共享问题。这个问题表现为GET和POST请求可以正常工作，但PUT和DELETE请求却无法通过CORS验证。这种情况在实际开发中并不少见，值得我们深入分析。

问题现象分析

当API部署在xyz.abc.com域名下，而前端Blazor应用部署在efg.abc.com域名时，虽然两个子域名属于同一主域(abc.com)，但浏览器仍然会将其视为跨域请求。特别是对于PUT和DELETE这类"非简单请求"，浏览器会先发送一个预检(OPTIONS)请求，只有预检通过后才会发送实际请求。

根本原因

1. 预检请求处理不当：对于PUT/DELETE等非简单请求，浏览器会先发送OPTIONS请求，而服务端可能没有正确配置对这些预检请求的响应。

2. CORS策略不完整：虽然配置了允许跨域，但可能缺少对特定HTTP方法(PUT/DELETE)的显式允许。

3. IIS特殊配置：IIS可能对OPTIONS请求有特殊处理，或者Web.config中缺少必要的配置。

解决方案

1. 完善CORS配置

在ASP.NET Core中，确保Startup.cs或Program.cs中正确配置了CORS策略：

services.AddCors(options =>
{
    options.AddPolicy("AllowSpecificOrigin",
        builder => builder.WithOrigins("https://efg.abc.com")
            .AllowAnyHeader()
            .AllowAnyMethod() // 确保包含PUT/DELETE
            .AllowCredentials());
});

2. 确保中间件顺序正确

CORS中间件需要在路由和身份验证中间件之前：

app.UseCors("AllowSpecificOrigin");
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();

3. IIS特殊配置

在Web.config中添加以下配置处理OPTIONS请求：

<system.webServer>
  <handlers>
    <remove name="OPTIONSVerbHandler" />
    <add name="OPTIONSVerbHandler" path="*" verb="OPTIONS" 
         modules="AspNetCoreModuleV2" resourceType="Unspecified" />
  </handlers>
</system.webServer>

4. 检查响应头

确保响应中包含以下头部：

• Access-Control-Allow-Origin: https://efg.abc.com
• Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
• Access-Control-Allow-Headers: content-type, authorization
• Access-Control-Allow-Credentials: true (如果需要)

验证步骤

1. 使用浏览器开发者工具检查网络请求，确认OPTIONS预检请求是否成功
2. 检查预检请求的响应头是否包含正确的CORS头部
3. 确保实际请求(PUT/DELETE)的Origin头部与允许的源匹配

总结

CORS问题在跨域开发中非常常见，特别是对于非简单请求。通过合理配置CORS策略、正确处理OPTIONS请求以及确保中间件顺序正确，可以解决大多数跨域问题。dotnet-webapi-starter-kit作为一个优秀的起点项目，理解其CORS配置机制对于项目成功部署至关重要。