abrufen der Nachricht: Verbotene Antwort vom AWS-API-Gateway

Wenn Sie die Option "API Key Required" auf "true" setzen, prüfen Sie bitte unten. 

1. sie müssen den HTTP-Header-Parameter 'x-api-key' an das API-Gateway übergeben. 
2. Der API-Schlüssel musste erstellt werden. 
3. Darüber hinaus müssen Sie einen Verwendungsplan für den API-Schlüssel in der API Gateway Console überprüfen.

Wählen Sie im API-Gateway-Dashboard Ressourcen aus, klicken Sie auf Aktionen und wählen Sie API bereitstellen. Vor Ihrer ersten Bereitstellung erhalten Sie nur den {"message":"Forbidden"}.

Wenn Sie einen benutzerdefinierten Domänennamen verwenden und die Auswahl des Ziel-Staging vergessen, wird die Meldung Forbidden angezeigt.

Gehen Sie einfach zu Custom Domain Names und klicken Sie unter Ihrer Domain auf Edit. Wählen Sie dann unter Base Path Mappings die Stufe aus.

Ich hatte ein ähnliches Problem und hatte folgendes:

1. Eine benutzerdefinierte Domäne (Edge-optimiert)
2. Mehrere Stufen (Dev, Staging, Prod)

Ich habe auch keine Autorisierung oder Einschränkungen festgelegt, um die Dinge zu vereinfachen.

Ich konnte das Problem durch Hinzufügen von Basispfadzuordnungen für jede meiner Stufen (dev, staging, prod) beheben.

Wenn sowohl Authorization als auch API KEY Required für die Methode auf true gesetzt sind, stellen Sie sicher, dass beim Senden der Anforderung die folgenden Header vorhanden sind:

1. Content-Type (normalerweise application/x-www-form-urlencoded bei GET-Aufruf)
2. Wirt
3. X-Amz-Datum
4. Genehmigung
5. x-api-key

Ich benutze POSTMAN für API-Tests, die ziemlich zuverlässig sind, und dann ist es vorgerückt.

Anmerkung: Fügen Sie keinen x-api-Schlüsselheader hinzu, wenn Sie API KEY REQUIRED als FALSE ..__ festgelegt haben. Wenn Sie AUTHORIZATION als FALSE festgelegt haben, fügen Sie keinen Autorisierungsheader hinzu. 

Wenn Sie den API-Schlüssel auf true setzen, müssen Sie den API-Schlüssel als Header übergeben.

Der API-Schlüssel wird als Headerfeld 'x-api-key' übergeben. Selbst nachdem Sie dieses Feld im Header hinzugefügt haben, kann dieses Problem auftreten. In diesem Fall bestätigen Sie bitte die folgenden Punkte

• Haben Sie einen Nutzungsplan? Wenn nicht müssen Sie einen erstellen.
• Verknüpfen Sie Ihre API mit dem Nutzungsplan. Für das Hinzufügen einer Phase wird Ihre API verlinkt.
• Haben Sie einen API-Schlüssel? Wenn nicht, müssen Sie einen API-Schlüssel erstellen und aktivieren.
• Fügen Sie den mit Ihrer API verknüpften Nutzungsplan zu diesem API-Schlüssel hinzu. Fügen Sie dazu einen Nutzungsplan hinzu.

Möglicherweise bin ich auf eine Lösung für dieses Problem gestoßen. Ich hatte im Moment das gleiche Problem unter MacOS. Ich habe versucht mein DNS zu leeren und dann hat es funktioniert!

Versuchen Sie dies im Terminal:

Mac OS X Yosemite und höher

Sudo killall -HUP mDNSResponder

Mac OS X Yosemite 10.10 bis 10.10.3

Sudo discoveryutil mdnsflushcache

Mac OS X Mavericks, Mountain Lion und Lion

Sudo killall -HUP mDNSResponder

Mac OS X Snow Leopard

Sudo dscacheutil -flushcache

Dies ist alles andere als offensichtlich, aber ein anderer Grund für die Anzeige des "Verbotenen" Fehlers bei der Verwendung von AWS API Gateway ist möglicherweise der Aufruf einer falschen URL, die keiner bereitgestellten API-Methode entspricht. Dies kann vorkommen, wenn Sie tatsächlich eine falsche URL verwenden (z. B. statt https://9999xx9x99.execute-api.us-east-1.amazonaws.com/dev/users (beachten Sie die Variable dev vor users), die Sie https://9999xx9x99.execute-api.us-east-1.amazonaws.com/users (keine Stufe) aufgerufen haben. Sie würden mit 404 rechnen, aber 403.

Übrigens: Nachdem Sie https://9999xx9x99.execute-api.us-east-1.amazonaws.com/dev/users aufgerufen haben, rufen Sie https://9999xx9x99.execute-api.us-east-1.amazonaws.com/user auf (beachten Sie die Singular-Nomenform hier), erhalten Sie auch… 403, jedoch mit der Meldung "Missing Authentication Token"!

Ich habe diesen Fehler von einem Nginx Fargate-Dienst erhalten, der versucht, auf eine private API in API Gateway zuzugreifen. Ich musste in meiner API so eine Richtlinie unter Ressourcenrichtlinien hinzufügen

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": "arn:aws:execute-api:us-east-1:<AccountID>:<RestApiID>/*",
            "Condition": {
                "StringEquals": {
                    "aws:sourceVpce": "<VPC Endpoint ID for execute-api>"
                }
            }
        }
    ]
}

Lokale Firewall/Antivirus oder NGIPS ( Cisco Bluecoat ). Letzteres war mein Fall, bei dem ich nicht einmal Protokolle in CloudWatch von meiner API erhalten würde. Es erlaubte meiner gehosteten Website auf oberster Ebene, blockierte jedoch mit 403 die api-Subdomain, ohne dass sich im Browser die Registerkarte dev-tools befand.

Es gibt ein paar Dinge zu tun, wenn wir die {message: forbidden} im API-Gateway erhalten:

CORS aktiviert?

1. Überprüfen Sie, ob CORS in der API aktiviert ist (zulassen Sie den Ursprung '*', um sicherzustellen, dass wir sicher testen können.)
2. Stellen Sie die API bereit, um sicherzustellen, dass alle Einstellungen wie erwartet sind

API Key aktiviert?

3. Überprüfen Sie, ob der API-Schlüssel im API-Gateway aktiviert ist
4. Überprüfen Sie, ob ein API-Schlüssel konfiguriert ist.
5. Prüfen Sie, ob Ihr API-Schlüssel dem korrekten Verwendungsplan zugewiesen ist, und fügen Sie eine API-Stufe hinzu. Ohne die API-Stufe erhalten Sie immer eine {message: forbidden}.

Wenn Sie immer noch Probleme haben, lassen Sie es mich wissen, damit ich oder einer unserer Cloud-Gurus @levarne helfen kann. 

Sie müssen Ihre API auf der Bühne bereitstellen. Verwenden Sie die Stage-URL. Gehen Sie zu Resources, klicken Sie auf Actions und wählen Sie API bereitstellen

Nun, wenn Sie Fehler bekommen 

{"message": "Forbidden"}.

Bitte überprüfen Sie die folgenden Schritte 

1) Wenn Sie die API-Schlüsselkopie aktivieren und Ihren Schlüssel als Postbote übergeben 

2) Wenn Sie jetzt immer noch dieselbe Fehlermeldung erhalten, müssen Sie einen Nutzungsplan erstellen 

3) setze ein Limit und ordne den Plan deiner API zu

Wir hatten dieses Problem in unserer Produktion, als wir Kong als API-Gateway verwendeten. Unsere Anfragen wurden von Postman initiiert, als sie von Postman initiiert wurden. Das Bot-Plugin in Kong wurde aktiviert, wodurch nur Anforderungen zugelassen wurden, die von Browser oder Mobile App basierend auf dem Header des Benutzeragenten-Headers initiiert wurden. Nachdem wir das Bot-Plugin deaktiviert hatten, trat der Fehler nicht auf. Es erlaubt jetzt eine Anfrage, wenn der Benutzeragent Apache-HttpClient/4.5.2 (Java/1.8.0_91) ist.

Ich bin zwar zu spät, aber einer der Gründe, warum API Gateway eine "Verbotene" Meldung geben würde, ist, wenn Sie Daten in der Anforderung "Body" für einen GET-Vorgang übergeben. Um das Problem zu lösen, erstellen Sie entweder Ihre Ressource POST oder übergeben Sie keine Daten in der Anforderung "Body".

Ich habe {"message":"Forbidden"} auf einer API mit EndpointConfiguration auf PRIVATE und einem dafür erstellten VpcEndpoint in den privaten Subnetzen der Vpc (dies ist eine dienstübergreifende API)

Der Grund, warum ich habe {"message":"Forbidden"} war, dass ich den Eindruck hatte, ich sollte eine der VpcEndpoint-URLs verwenden. Die zu verwendende URL ist weiterhin die mit der Bühne verknüpfte URL (in der ApiGateway-Konsole). Es ist:

https://${RestApiId}.execute-api.${Region}.amazonaws.com/${StageName}