解决AWS SAM中API Gateway与Cognito授权时的CORS问题

在AWS Serverless Application Model (SAM)项目中，当开发者尝试为API Gateway配置Cognito授权并启用CORS时，经常会遇到500错误和CORS策略问题。本文将深入分析这一常见问题的根源，并提供完整的解决方案。

问题现象分析

当开发者按照常规方式配置API Gateway和Cognito授权后，前端应用在访问API时通常会遇到以下错误：

Access to fetch at 'API_ENDPOINT' from origin 'localhost:3000' has been blocked by CORS policy: 
Response to preflight request doesn't pass access control check: It does not have HTTP ok status.

通过curl测试OPTIONS请求时，会得到500错误响应，这表明问题发生在API Gateway层面，请求甚至没有到达Lambda函数。

根本原因

这个问题主要由两个关键因素导致：

1. 预检请求(OPTIONS)被授权拦截：当API Gateway配置了Cognito授权后，默认情况下OPTIONS方法也会被要求授权，而浏览器发起的预检请求不携带授权信息。

2. API Gateway部署缓存：有时对API配置的修改可能不会立即生效，导致看似正确的配置实际上未被应用。

完整解决方案

1. 禁用预检请求的授权

在API Gateway的Auth配置中，必须明确设置AddDefaultAuthorizerToCorsPreflight: false，确保OPTIONS方法不会被要求授权：

Auth:
  DefaultAuthorizer: CognitoAuthorizer
  Authorizers:
    CognitoAuthorizer:
      UserPoolArn: !Ref CognitoUserPoolArn
  AddDefaultAuthorizerToCorsPreflight: false

2. 强制API Gateway部署

添加AlwaysDeploy: true属性确保配置变更一定会触发新的部署：

MyGatewayApi:
  Type: AWS::Serverless::Api
  Properties:
    AlwaysDeploy: true
    # 其他配置...

3. 完整的CORS响应头配置

确保Lambda函数返回正确的CORS头信息：

return {
    'statusCode': 200,
    'body': json.dumps(response_data),
    'headers': {
        'Access-Control-Allow-Origin': '*',
        'Access-Control-Allow-Headers': 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token',
        'Access-Control-Allow-Methods': '*',
        'Content-Type': 'application/json'
    }
}

4. API Gateway级别的CORS配置

在API Gateway资源上启用全局CORS支持：

Cors: "'*'"

最佳实践建议

1. 环境隔离：为不同环境(dev/staging/prod)使用不同的API Gateway实例，避免配置冲突。

2. 最小权限原则：虽然示例中使用'*'作为通配符，生产环境中应限制允许的来源、方法和头信息。

3. 监控与日志：启用API Gateway的访问日志，便于调试CORS相关问题。

4. 分阶段部署：先测试不带授权的API，确保CORS工作正常后再添加授权层。

总结

通过正确配置API Gateway的CORS和授权设置，开发者可以轻松解决Cognito授权与CORS的兼容性问题。关键在于理解预检请求的特殊性，并确保API Gateway配置能够正确处理这些请求。本文提供的解决方案已在生产环境中验证有效，开发者可以放心采用。