amazon-web-services - AWS API Gateway 仅在使用 SAM 时才支持 CORS for OPTIONS(没有 Lambda 代理集成)

Question

我正在使用 AWS Serverless用于构建具有大约 15 个 Lambda 函数的小型站点。
我的 Cloudformation 堆栈是完全使用 SAM 构建的.

我没有使用 Lambda 代理集成。
SAM 中的 Api 部分yaml 模板配置如下所示:

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

当我部署此 SAM yaml 模板，我看到我的 ApiGateway 为所有方法创建了 OPTIONS 动词，当我使用 OPTIONS 动词发出请求时，我确实看到了 CORS header 正确。

问题是其他动词(例如 POST)没有像 OPTIONS 请求那样将这些 header 添加到它们的响应中，并且当我从浏览器运行我的 api 时，我在控制台中收到了跨源策略错误。

所以我目前的解决方法是使用特定状态代码的集成响应添加 CORS header ，但我不能也不想处理 15 种方法，我想支持所有响应状态代码(例如 4xx\5xx 等)。

我的问题:

我在这里做错了什么还是这是一个 SAM漏洞？

如果这是一个错误，除了使用集成响应(或来自我的代码)添加 header 之外，还有其他解决方法吗？

有没有办法可以从 Api 网关“全局”添加 header ？或者支持某种全局综合 react ？

Answer 1

如果您将 Lambda 与代理集成一起使用，则需要在 HTTP 响应中指定 CORS 源。

For Lambda or HTTP proxy integrations, you can still set up the required OPTIONS response headers in API Gateway. However, you must rely on the back end to return the Access-Control-Allow-Origin headers because the integration response is disabled for the proxy integration. https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html

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

你可能已经有了这个，但 NodeJS 模式是这样的:

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

如果您真的不想这样做，那么您可以关闭 Lambda-Proxy 集成，但这意味着所有请求响应负载都需要在 API-G 而不是 Lambda 中处理。 IMO 这提供了实现相同结果所需的更少的灵活性和更多的配置。

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