解决fullstackhero/dotnet-starter-kit项目中的CORS跨域问题

在基于fullstackhero/dotnet-starter-kit项目进行开发时，很多开发者会遇到一个常见的跨域资源共享(CORS)问题：GET和POST请求可以正常工作，但PUT和DELETE请求却无法通过CORS验证。本文将深入分析这个问题的原因，并提供完整的解决方案。

问题现象分析

当项目部署在IIS服务器上时，API服务(如https://xyz.abc.com)和前端Blazor应用(如https://efg.abc.com)位于不同域名下。此时会出现以下现象：

1. GET和POST请求能够正常执行
2. PUT和DELETE请求被浏览器拦截，出现CORS错误
3. 控制台显示预检请求(OPTIONS)失败

问题根本原因

这种选择性失效的现象源于CORS的安全机制。浏览器对于"简单请求"和"非简单请求"有不同的处理方式：

1. 简单请求：GET、HEAD、POST方法，且Content-Type为特定值(如application/x-www-form-urlencoded、multipart/form-data、text/plain)
2. 非简单请求：PUT、DELETE等方法，或使用自定义头部、非简单Content-Type的请求

对于非简单请求，浏览器会先发送一个OPTIONS预检请求，只有预检通过后才会发送实际请求。

解决方案

1. 配置CORS策略

在ASP.NET Core项目中，需要正确配置CORS策略：

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

2. 中间件顺序

确保CORS中间件在管道中的正确顺序：

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

3. IIS特定配置

在IIS中部署时，可能需要额外配置：

1. 确保IIS的CORS模块已安装
2. 检查web.config中的CORS相关设置
3. 确认IIS应用程序池使用集成管道模式

4. 预检请求处理

确保服务器正确处理OPTIONS请求：

// 在控制器中添加
[HttpOptions]
public IActionResult Options()
{
    return Ok();
}

验证与测试

配置完成后，应进行以下验证：

1. 使用浏览器开发者工具检查网络请求
2. 确认OPTIONS请求返回200状态码
3. 检查响应头中包含正确的CORS相关头部
4. 测试所有HTTP方法(GET, POST, PUT, DELETE)

总结

fullstackhero/dotnet-starter-kit项目中的CORS问题主要源于对非简单请求的处理不足。通过正确配置CORS策略、确保中间件顺序、处理OPTIONS请求以及适当的IIS配置，可以彻底解决PUT和DELETE方法的跨域问题。理解CORS的工作原理对于现代Web开发至关重要，它能帮助开发者构建更安全、更灵活的跨域应用。