AWS API Gateway自定义Authorizer奇怪显示错误

Arm*_*man 12 custom-authentication aws-api-gateway

以下是上下文:

  • 我在API网关中设置了一个资源./用户/企业
  • 该资源有2种方法.获取并发布.
  • 我为此资源配置了自定义授权程序.

问题:

  • 我可以通过发送正确的授权信息来调用GET方法,并按预期获得结果.
  • 我尝试发送POST请求,我收到以下错误:

{
  "message": "User is not authorized to access this resource"
}
Run Code Online (Sandbox Code Playgroud)

  • 如果我等待几分钟,然后调用POST方法,它将工作.
  • 如果在调用POST方法并获得结果后我调用GET方法,它将显示与上面提到的相同的错误.

另外,我已经为授权者禁用了缓存.

在此输入图像描述

可能是什么导致了这个问题?

Mic*_*nov 25

event.methodArn由于策略缓存的工作方式,如果您将其用作生成策略的资源并在不同功能之间共享授权方,则会发生此错误。对于提供的令牌,它在整个 API 中缓存策略,对于同一 API 和阶段中的所有方法和资源(如果它们共享相同的授权者),它将是相同的缓存条目。

例如,当向 发出请求时GET /users,ARN 将如下所示:

arn:aws:execute-api:us-1:abc:123/prod/GET/users
Run Code Online (Sandbox Code Playgroud)

对具有相同身份验证令牌的任何端点的下一次调用将使用缓存策略,该策略是在第一次调用GET /users. 该缓存策略的问题在于它的资源只允许单个特定资源arn: ... /prod/GET/users,任何其他资源都将被拒绝。

根据您想要限制策略权限的程度,您可以在创建策略时提及每个可能的资源

{
  "principalId": "user",
  "policyDocument": {
    "Statement": [
      {
        "Action": "execute-api:Invoke",
        "Effect": "Allow",
        "Resource": [
          "arn:aws:execute-api:us-1:abc:123/prod/GET/v1/users",
          "arn:aws:execute-api:us-1:abc:123/prod/POST/v1/users",
          "arn:aws:execute-api:us-1:abc:123/prod/GET/v1/orders"
        ]
      }
    ],
    "Version": "2012-10-17"
  }
}
Run Code Online (Sandbox Code Playgroud)

或使用通配符

"Resource": "arn:aws:execute-api:us-1:abc:123/prod/*/v?/*"
Run Code Online (Sandbox Code Playgroud)

甚至

"Resource": "*"
Run Code Online (Sandbox Code Playgroud)

您可以将策略变量用于某些高级模板。

也可以通过允许使用通配符的所有内容然后在另一个策略声明中拒绝特定资源来使用黑名单方法。

资料来源:

  • 我想这应该是最好的答案。将 TTL 设置为 0(禁用缓存)将使授权者在调用您的端点时被调用。这可能不是开发者想要的。 (5认同)
  • 这是一个很好的答案,因为它描述了实际问题是什么。 (3认同)
  • 同意上述内容:这个答案解释了问题是什么以及如何解决它。在不知道“为什么”的情况下关闭缓存似乎是错误的方法。 (2认同)

Ore*_*est 12

可以通过越野车的答案中描述的两个选项来解决此问题:https : //forum.serverless.com/t/rest-api-with-custom-authorizer-how-are-you-dealing-with-authorization-and-策略缓存/ 3310

简洁版本:

  1. 将客户授权者的TTL设置为0
  2. 将自定义授权者策略资源设置为“ *”

我尝试了每种解决方案,他们都为我解决了“用户无权访问此资源”的问题。

  • 将 TTL 设置为 0 就可以了。如果有人使用 cf 或 sam,请使用模板中的 ReauthorizeEvery 属性。 (2认同)
  • 这确实可以解决问题,但是如果确实需要缓存怎么办? (2认同)