Api Gateway Api Key 创建后立即使用，禁止 [英] Api Gateway Api Key immediate use upon creation giving forbidden

问题描述

应用程序基于每个用户创建一个 api 密钥，其过程如下:

Application creates an api key on a per user basis, meaning the process is as follows:

• Lambda 函数创建 API 密钥并添加到使用计划中
• 从 lambda 函数返回 Api 键值
• 然后立即使用 Api 密钥调用 Api 网关端点
• 返回禁止的消息

如果我在 api 密钥创建和对 api 网关端点的 http 请求之间延迟执行(大约 5 秒)，那么它会按预期工作，但不到这个时间我会收到错误.

If I delay execution between api key creation and the http request to the api gateway end point (by around 5 seconds), then it works as intended, but less than that I get an error.

我怀疑 api 密钥需要几秒钟才能传播到端点，但我找不到一个 AWS API 方法可以正确地让我知道何时这样做.有没有人遇到过这个问题，你是怎么解决的?

I suspect that the api key takes a few seconds to propagate to the endpoint but I can't find an AWS API method that correctly lets me know when it has done so. Has anyone come across this problem before and how did you solve it?

我目前最好的解决方案是在滑动超时时重试 api 调用，直到经过了不合理的时间.

The best solution I have at the moment is to retry the api call on a sliding timeout until an unreasonable amount of time has passed.

推荐答案

在应用 AWS IAM 策略之后我应该等待多长时间是有效的吗? 不是同一个问题，但在其基本解释中似乎很相似——这并不是 API 密钥需要时间存在的情况，而是需要时间传播并在所有可能的情况下变得可见在它对任何后续请求有效之前可能需要存在的地方.

How long should I wait after applying an AWS IAM policy before it is valid? is not the same question but seems likely to be similar in its underlying explanation -- it's not so much a case of the API key taking time to exist but rather taking time to propagate and become visible at every possible place where it might need to exist before being valid for any subsequent request.

如果这些假设是正确的，则没有机制可以权威地确定密钥是否可以使用，因为在密钥创建请求成功后的一段时间内，它的情况可以说让人想起薛定谔的猫——密钥既存在又不存在——你不知道，直到你尝试它，并且(与猫不同)即使成功的测试也不一定证明它完全可以使用，因为可能性(但不太可能)) 的结果，例如失败失败失败失败通过失败通过通过通过.这是许多大型分布式系统的特征行为.

If those assumptions are correct, there is no mechanism for authoritatively determining whether the key is ready for use or not, because for some period of time after the key creation request succeeds, it's in a situation arguably reminiscent of Schrödinger's cat -- the key both exists and doesn't exist -- you don't know until you try it, and (unlike the cat) even a successful test does not necessarily prove that it is fully ready for use, because of the possibility (however unlikely) of a result such as fail fail fail fail pass fail pass pass pass. Such is the characteristic behavior of many large-scale, distributed systems.

来自评论:

如果 API 调用返回 api 键值，那么我希望它能够立即使用，或者至少仅在键完全传播到端点时才返回.

If an API call returns the api key value then I would expect it to be able to be used instantly, or at least return only when the key has been propagated fully to the end points.

这表面上是有道理的，但实施起来就成了问题.如果其中一个端点出现故障、离线进行维护，或者正在从中断和滞后中恢复，该怎么办……然后呢?请求失败?延迟响应等待统计上不太可能影响您的事情?

That makes sense on the surface, but it becomes problematic in implementation. What if one of the endpoints is failed, offline for maintenance, or in the middle of recovering from an outage and lagging... what then? Fail the request? Delay the response waiting for something statistically unlikely to impact you?

在许多情况下，观察复制的资源成本往往超过收益，并且如果复制问题导致足够的积压，则可能会破坏系统的控制平面，并且通常不会实施，除非它具有很高的价值，即GetChange action in Route 53 它允许您验证更改在系统中的传播——请注意，即使在这种情况下，更改请求本身也会成功而无需等待——如果您需要验证同步状态，你要单独问.

The resource cost of observing replication tends to outweigh the benefits in many cases and can destabilize the control plane of a system if a replication issue causes a sufficient backlog, and is often not implemented except in cases where it has a high value, viz. the GetChange action in Route 53 which allows you to verify the propagation of a change through the system -- and note that even in this case, the change request itself succeeds without waiting -- if you need to verify the sync state, you have to ask separately.

这篇关于Api Gateway Api Key 创建后立即使用，禁止的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！