Api-Gateway Api Key sofortiger Einsatz bei der Erstellung verboten Geben

Question

Anwendung schafft einen API-Schlüssel auf einer Pro-Benutzer-Basis, das heißt, der Prozess wie folgt:

• Lambda-Funktion erstellt Schlüssel api und fügt an einen Nutzungsplan
• Api Schlüsselwert von Lambda-Funktion zurückgegeben wird
• Api Schlüssel wird dann sofort verwendet, um einen API-Gateway Endpunkt zu nennen
• Verbotene Meldung zurückgegeben

Wenn ich die Ausführung zwischen API-Erstellung und HTTP-Anforderung an den API-Gateway-Endpunkt verzögern (um etwa 5 Sekunden), dann funktioniert es wie beabsichtigt, aber weniger als das erhalte ich einen Fehler.

Ich vermute, dass der API-Schlüssel ein paar Sekunden dauert, um an den Endpunkt zu propagieren, aber ich kann keine AWS-API-Methode finden, die mich korrekt informiert, wenn dies der Fall ist. Hat jemand schon einmal auf dieses Problem gestoßen und wie haben Sie es gelöst?

Die beste Lösung, die ich im Moment habe, besteht darin, den API-Aufruf mit einem gleitenden Timeout zu wiederholen, bis eine unangemessene Zeit verstrichen ist.

Answer 1

How long should I wait after applying an AWS IAM policy before it is valid? ist nicht die gleiche Frage, aber scheint in der zugrunde liegenden Erklärung ähnlich zu sein - es ist nicht so sehr ein Fall des API-Schlüssels, der Zeit braucht, um sich zu verbreiten und an jedem möglichen Ort sichtbar zu werden Möglicherweise muss es existieren, bevor es für eine nachfolgende Anfrage gültig ist.

Wenn diese Annahmen richtig sind, gibt es keinen Mechanismus, um autoritativ zu bestimmen, ob der Schlüssel einsatzbereit ist oder nicht, denn für eine gewisse Zeit nach der erfolgreichen Schlüsselerstellung ist es in einer Situation, die wohl an Schrödingers Katze erinnert - - Der Schlüssel existiert und existiert nicht - Sie wissen es nicht, bis Sie es versuchen, und (im Gegensatz zur Katze) beweist selbst ein erfolgreicher Test nicht unbedingt, dass er vollständig einsatzbereit ist, wegen der Möglichkeit (jedoch unwahrscheinlich) eines Ergebnisses, wie z. B. fehlgeschlagen, fehlgeschlagen, fehlgeschlagen, fehlgeschlagen, fehlgeschlagen, pass pass pass. Dies ist das charakteristische Verhalten vieler großer, verteilter Systeme.

---

Von Kommentaren:

Wenn ein API-Aufruf des api Schlüsselwert zurückgibt, dann würde ich erwarten, dass es in der Lage sein, sofort verwendet werden, oder zumindest Rückkehr nur, wenn der Schlüssel propagiert wurde vollständig zu den Endpunkten.

Das macht auf der Oberfläche Sinn, aber es wird problematisch in der Umsetzung. Was ist, wenn einer der Endpunkte ausgefallen ist, zu Wartungszwecken offline ist oder gerade in der Lage ist, sich von einem Ausfall und einer Verzögerung zu erholen ... was dann? Fail die Anfrage? Verzögerung der Antwort auf etwas warten, das statistisch unwahrscheinlich ist, um Sie zu beeinflussen?Die Ressourcenkosten zum Beobachten der Replikation tendieren dazu, die Vorteile in vielen Fällen zu überwiegen und die Kontrollebene eines Systems zu destabilisieren, wenn ein Replikationsproblem einen ausreichenden Rückstand verursacht, und wird oft nur in Fällen mit hohem Wert implementiert , viz. die GetChange action in Route 53 die Sie die Weitergabe einer Änderung durch das System überprüfen können - und beachten Sie, dass auch in diesem Fall die Änderungsanforderung selbst ohne Warten erfolgreich ist - wenn Sie den Synchronisierungsstatus überprüfen müssen, müssen Sie separat fragen.

Answer 2

Viele AWS-Dienste benötigen Zeit zum Erstellen. Normalerweise gibt es eine Möglichkeit festzustellen, ob der Job abgeschlossen wurde. In diesem Fall sieht es so aus, als ob Sie eine verbotene Antwort erhalten, bis der Schlüssel erstellt wurde.

Ich denke, dass Sie in Ihrem Client damit umgehen müssen.