Question

我正在使用AWS Serverless来构建一个具有15个Lambda函数的小型网站。
我的Cloudformation堆栈是完全使用SAM构建的。

我没有使用Lambda代理集成。

SAM yaml模板配置中的Api部分如下所示：

AppApi:
    Type: AWS::Serverless::Api
    Properties:
        Cors:
            AllowMethods: "'*'"
            AllowHeaders: "'Content-Type'" 
            AllowOrigin: "'*'"
    ...........More Stuff..........

当我部署这个SAM yaml模板时，我看到我的ApiGateway为所有方法创建了OPTIONS动词，当我用OPTIONS动词拍摄请求时，我确实看到了CORS标头。

问题是其他动词（例如POST）没有像OPTIONS请求那样将那些标头添加到其响应中，并且当我从浏览器运行api时，我的控制台中出现了跨源策略错误。

所以我当前的解决方法是使用对特定状态代码的集成响应来添加CORS标头，但是我不能也不希望为15种方法处理该响应，并且我想支持所有响应状态代码（例如4xx \ 5xx等）。

我的问题：

我在这里做错什么了吗，或者这是一个SAM错误？
如果这是一个错误，除了使用集成响应（或从我的代码）添加标头之外，还有其他解决方法吗？
有没有一种方法可以从Api网关“全局”添加标头？还是支持某种全球性综合应对措施？

Answer 1

如果您将Lambda与Proxy Integrations一起使用，则需要在HTTP响应中指定CORS来源。

对于Lambda或HTTP代理集成，您仍然可以设置 API网关中必需的OPTIONS响应标头。但是，您必须依靠后端返回Access-Control-Allow-Origin标头因为禁用了代理的集成响应积分。 https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html

所有来自Lambda的响应都需要具有这些标头和状态代码，但是您可以将其提取到共享库中以减少代码重复。由API-G处理的错误将自动添加标头。

您可能已经拥有了，但是NodeJS模式是这样的：

var response = {
    statusCode: 200,
    headers: {
        "Access-Control-Allow-Origin" : "*"
    },
    body: JSON.stringify({
        someReturnData
    })
};
callback(null, response);

如果您真的不想执行此操作，则可以关闭Lambda-Proxy集成，但这意味着所有请求响应有效负载都需要在API-G中而不是Lambda中进行处理。 IMO提供的灵活性要差得多，而实现相同结果所需的配置更多。

Here是这两种方法的有趣比较。

AWS API Gateway仅在使用SAM时支持OPTIONS的CORS（无Lambda代理集成）

1 个答案: