GSP844

Übersicht

Apigee ist eine Plattform zum Entwickeln und Verwalten von APIs. Mit Apigee können Sie den Zugriff auf Ihre APIs schützen und per Ratenbegrenzung limitieren. Apigee bietet auch Funktionen, mit denen der interne Zugriff auf API-Daten geschützt werden kann.

In diesem Lab erstellen Sie eine API, für die OAuth-Tokens für den Zugriff erforderlich sind. Sie verwenden die SpikeArrest-Richtlinie, um die Rate von API-Aufrufen pro Anwendung zu begrenzen, und private Variablen und Datenmaskierung, um sensible Daten vor Nutzern zu verbergen, die API-Traffic debuggen.

Ziele

Aufgaben in diesem Lab:

• Zugriff auf APIs durch Anfordern eines OAuth-Tokens schützen
• Gesamtrate des Traffics und Rate nach Anwendung mit der SpikeArrest-Richtlinie begrenzen
• Private Variablen und Datenmaskierung verwenden, um sensible Daten beim Debuggen von API-Aufrufen auszublenden
• Aufrufe des Backends auf bestimmte Ressourcen beschränken
• Backend-Fehlermeldungen neu schreiben, um Datenlecks zu verhindern

Einrichtung und Anforderungen

Vor dem Klick auf „Start Lab“ (Lab starten)

Lesen Sie diese Anleitung. Labs sind zeitlich begrenzt und können nicht pausiert werden. Der Timer beginnt zu laufen, wenn Sie auf Lab starten klicken, und zeigt Ihnen, wie lange Google Cloud-Ressourcen für das Lab verfügbar sind.

In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung durchführen – nicht in einer Simulations- oder Demo-Umgebung. Dazu erhalten Sie neue, temporäre Anmeldedaten, mit denen Sie für die Dauer des Labs auf Google Cloud zugreifen können.

Für dieses Lab benötigen Sie Folgendes:

• Einen Standardbrowser (empfohlen wird Chrome)

Hinweis: Nutzen Sie den privaten oder Inkognitomodus (empfohlen), um dieses Lab durchzuführen. So wird verhindert, dass es zu Konflikten zwischen Ihrem persönlichen Konto und dem Teilnehmerkonto kommt und zusätzliche Gebühren für Ihr persönliches Konto erhoben werden.

• Zeit für die Durchführung des Labs – denken Sie daran, dass Sie ein begonnenes Lab nicht unterbrechen können.

Hinweis: Verwenden Sie für dieses Lab nur das Teilnehmerkonto. Wenn Sie ein anderes Google Cloud-Konto verwenden, fallen dafür möglicherweise Kosten an. Hinweis: Es wird empfohlen, für dieses Lab ein neues Inkognitofenster zu verwenden.

Lab starten und bei der Google Cloud Console anmelden

1. Klicken Sie auf Lab starten. Wenn Sie für das Lab bezahlen müssen, wird ein Dialogfeld geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können. Auf der linken Seite befindet sich der Bereich „Details zum Lab“ mit diesen Informationen:

   • Schaltfläche „Google Cloud Console öffnen“
   • Restzeit
   • Temporäre Anmeldedaten für das Lab
   • Ggf. weitere Informationen für dieses Lab

2. Klicken Sie auf Google Cloud Console öffnen (oder klicken Sie mit der rechten Maustaste und wählen Sie Link in Inkognitofenster öffnen aus, wenn Sie Chrome verwenden).

   Im Lab werden Ressourcen aktiviert. Anschließend wird ein weiterer Tab mit der Seite „Anmelden“ geöffnet.

   Tipp: Ordnen Sie die Tabs nebeneinander in separaten Fenstern an.

   Hinweis: Wird das Dialogfeld Konto auswählen angezeigt, klicken Sie auf Anderes Konto verwenden.

3. Kopieren Sie bei Bedarf den folgenden Nutzernamen und fügen Sie ihn in das Dialogfeld Anmelden ein.

   {{{user_0.username | "Username"}}}

   Sie finden den Nutzernamen auch im Bereich „Details zum Lab“.

4. Klicken Sie auf Weiter.

5. Kopieren Sie das folgende Passwort und fügen Sie es in das Dialogfeld Willkommen ein.

   {{{user_0.password | "Password"}}}

   Sie finden das Passwort auch im Bereich „Details zum Lab“.

6. Klicken Sie auf Weiter.

   Wichtig: Sie müssen die für das Lab bereitgestellten Anmeldedaten verwenden. Nutzen Sie nicht die Anmeldedaten Ihres Google Cloud-Kontos. Hinweis: Wenn Sie Ihr eigenes Google Cloud-Konto für dieses Lab nutzen, können zusätzliche Kosten anfallen.

7. Klicken Sie sich durch die nachfolgenden Seiten:

   • Akzeptieren Sie die Nutzungsbedingungen.
   • Fügen Sie keine Wiederherstellungsoptionen oder Zwei-Faktor-Authentifizierung hinzu (da dies nur ein temporäres Konto ist).
   • Melden Sie sich nicht für kostenlose Testversionen an.

Nach wenigen Augenblicken wird die Google Cloud Console in diesem Tab geöffnet.

Hinweis: Wenn Sie auf Google Cloud-Produkte und ‑Dienste zugreifen möchten, klicken Sie auf das Navigationsmenü oder geben Sie den Namen des Produkts oder Dienstes in das Feld Suchen ein.

Cloud Shell aktivieren

Cloud Shell ist eine virtuelle Maschine, auf der Entwicklertools installiert sind. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Mit Cloud Shell erhalten Sie Befehlszeilenzugriff auf Ihre Google Cloud-Ressourcen.

1. Klicken Sie oben in der Google Cloud Console auf Cloud Shell aktivieren .

2. Klicken Sie sich durch die folgenden Fenster:

   • Fahren Sie mit dem Informationsfenster zu Cloud Shell fort.
   • Autorisieren Sie Cloud Shell, Ihre Anmeldedaten für Google Cloud API-Aufrufe zu verwenden.

Wenn eine Verbindung besteht, sind Sie bereits authentifiziert und das Projekt ist auf Project_ID, eingestellt. Die Ausgabe enthält eine Zeile, in der die Project_ID für diese Sitzung angegeben ist:

Ihr Cloud-Projekt in dieser Sitzung ist festgelegt als {{{project_0.project_id | "PROJECT_ID"}}}

gcloud ist das Befehlszeilentool für Google Cloud. Das Tool ist in Cloud Shell vorinstalliert und unterstützt die Tab-Vervollständigung.

3. (Optional) Sie können den aktiven Kontonamen mit diesem Befehl auflisten:

gcloud auth list

4. Klicken Sie auf Autorisieren.

Ausgabe:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} Um das aktive Konto festzulegen, führen Sie diesen Befehl aus: $ gcloud config set account `ACCOUNT`

5. (Optional) Sie können die Projekt-ID mit diesem Befehl auflisten:

gcloud config list project

Ausgabe:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Hinweis: Die vollständige Dokumentation für gcloud finden Sie in Google Cloud in der Übersicht zur gcloud CLI.

Apigee-Konsole öffnen

So öffnen Sie die Apigee-Konsole:

• Geben Sie in der Google Cloud Console in das Feld Suchen Apigee ein und klicken Sie dann in den Suchergebnissen auf Apigee API Management.

Die Apigee-Konsole wird geöffnet und auf der Landingpage werden Quick Links zu häufig verwendeten Standorten angezeigt.

• Klicken Sie im Navigationsmenü () neben Apigee auf Favorisieren ().

Apigee wurde dem Navigationsmenü als Favorit hinzugefügt.

Aufgabe 1: Backend-Dienst über einen Apigee API-Proxy weiterleiten

In dieser Aufgabe erstellen Sie einen Apigee API-Proxy, der als Fassade für einen Backend-Dienst fungiert. Der API-Proxy verwendet ein Dienstkonto, damit er OpenID Connect-Identitätstokens für den Cloud Run-Dienst präsentieren kann.

Ein Backend-Dienst mit dem Namen simplebank-rest wurde bereits erstellt und in Cloud Run bereitgestellt. Außerdem wurde ein Dienstkonto für Sie erstellt.

Apigee-Proxy erstellen

1. Verwenden Sie in Cloud Shell den folgenden Befehl, um die URL für den Backend-Dienst abzurufen:

   gcloud run services describe simplebank-rest --platform managed --region {{{project_0.default_region |REGION}}} --format 'value(status.url)'

   Speichern Sie diese URL, da sie beim Erstellen des API-Proxys verwendet wird.

2. Rufen Sie die Apigee-UI in der Cloud Console auf.

3. Wählen Sie im Navigationsmenü auf der linken Seite Proxy-Entwicklung > API-Proxys aus.

4. Wenn Sie einen neuen Proxy mit dem Proxy-Assistenten erstellen möchten, klicken Sie auf + Erstellen.

   Sie erstellen einen Reverse-Proxy für Ihren Backend-Dienst. Für diesen API-Proxy wird eine OpenAPI-Spezifikation verwendet, um ein Gerüst für die API zu erstellen.

5. Wählen Sie im Feld Proxyvorlage unter OpenAPI-Spezifikationsvorlage die Option Reverse-Proxy (häufigste Option) aus.

6. Öffnen Sie die folgende URL in einem Browser, um die OpenAPI-Datei zu erhalten. Die YAML-Datei mit der OpenAPI-Spezifikation wird auf Ihren Computer heruntergeladen:

   https://storage.googleapis.com/spls/gsp844/simplebank-backend.yaml

7. Klicken Sie auf Durchsuchen, wählen Sie die Datei auf dem Computer als OpenAPI-Datei aus und klicken Sie auf Weiter.

8. Geben Sie für die Proxydetails Folgendes an:

   Attribut	Wert
   Proxyname	bank-v1
   Basispfad	/bank/v1
   Beschreibung	Schreibgeschützte SimpleBank-API
   Ziel (vorhandene API)	Backend-URL

   Hinweis: Prüfen Sie, ob Sie „/bank/v1“ für den Basispfad verwenden und nicht „/bank-v1“.

   Das Ziel sollte die Backend-URL sein, die Sie zuvor in der Aufgabe abgerufen haben. Das Ziel sollte in etwa so aussehen:

   https://simplebank-rest-nu7rb74j5a-uw.a.run.app

9. Klicken Sie auf Weiter.

10. Übernehmen Sie die anderen Standardeinstellungen und klicken Sie auf Erstellen.

11. Klicken Sie auf den Tab Entwickeln.

    Hinweis: Dem Proxy-Endpunkt wurden Abläufe hinzugefügt, in denen jeweils ein Verb und eine Pfadbedingung eines der Vorgänge aus der OpenAPI-Spezifikation angegeben sind.

Ziel so ändern, dass ein OpenID Connect-Identitätstoken gesendet wird

Der Backend-Dienst ist so bereitgestellt, dass ein authentifizierter Zugriff erforderlich ist. Sie können den Dienst also nicht ohne ein gültiges OpenID Connect-Identitätstoken aufrufen.

Mit HTTPTargetConnection wird das Backend-Ziel für den Dienst angegeben.

1. Klicken Sie im Navigationsmenü des Proxys im Bereich Zielendpunkte auf PreFlow.

2. Suchen Sie den folgenden Code (Ihre URL ist anders):

   <HTTPTargetConnection> <URL>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</URL> </HTTPTargetConnection> Hinweis: Wenn der Abschnitt „HTTPTargetConnection“ nicht angezeigt wird, haben Sie möglicherweise auf „PreFlow“ im Abschnitt „Proxy-Endpunkte“ statt im Abschnitt „Zielendpunkte“ geklickt.

3. Fügen Sie unter der URL einen Abschnitt Authentifizierung hinzu, der so aussieht:

   <Authentication> <GoogleIDToken> <Audience>AUDIENCE</Audience> </GoogleIDToken> </Authentication>

4. Ersetzen Sie AUDIENCE durch den URL-Wert, der bereits im Abschnitt HTTPTargetConnection enthalten ist. Ihr Code sollte jetzt etwa so aussehen, wobei die Elemente „URL“ und „Audience“ Ihre spezifische URL enthalten:

   <TargetEndpoint name="default"> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <Flows/> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <HTTPTargetConnection> <URL>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</URL> <Authentication> <GoogleIDToken> <Audience>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</Audience> </GoogleIDToken> </Authentication> </HTTPTargetConnection> </TargetEndpoint>

5. Klicken Sie auf Speichern.

Klicken Sie auf Fortschritt prüfen. API-Proxy erstellen

Aufgabe 2: OAuth zum API-Proxy hinzufügen

In dieser Aufgabe fügen Sie dem API-Proxy eine OAuthV2-Richtlinie hinzu. Eine OAuthV2-Richtlinie mit dem Vorgang VerifyJWTAccessToken erzwingt die Überprüfung von Zugriffstokens zur Laufzeit, sodass nur Anwendungen mit einem gültigen OAuth-Zugriffstoken auf die API zugreifen können.

Mit der OAuthV2-Richtlinie können sowohl intransparente Tokens als auch JSON Web Tokens (JWTs) erstellt und überprüft werden. Für die Zugriffstokens werden in diesem API-Proxy JWTs verwendet.

Zum Speichern des Signatur-Secrets, das beim Erstellen und Überprüfen des JWT verwendet wird, wird ein Attributsatz verwendet.

Signatur-Secret im Attributsatz erstellen

Das JWT wird mit einem Hash-basierten Nachrichten-Authentifizierungscode (HMAC) signiert. Für diese Art der kryptografischen Signierung ist ein Secret erforderlich.

1. Klicken Sie im Navigatormenü für den Proxy neben Ressourcen auf +.

2. Wählen Sie im Drop-down-Menü Ressourcentyp die Option Attributsatz aus.

3. Geben Sie oauth.properties für den Ressourcennamen an und klicken Sie dann auf Hinzufügen.

4. Fügen Sie im Codebereich oauth.properties das folgende Attribut hinzu:

   secret=thisisnotagoodsecret,useabettersecretinproduction

   Auf diesen Wert kann im Code mit der Ablaufvariablen propertyset.oauth.secret zugegriffen werden.

   Hinweis: Werte für Attributgruppen werden als Nur-Text gespeichert. In einer Produktionsumgebung würden Sie das HMAC-Secret wahrscheinlich an einem verschlüsselten Ort speichern und auf jeden Fall ein sichereres (zufälliges) Secret verwenden.

AssignMessage-Richtlinie zum Abrufen des Attributsatzwerts hinzufügen

Das Signatur-Secret muss der OAuth-Richtlinie in einer privaten Variablen zur Verfügung gestellt werden. Die Variable „propertyset.oauth.secret“ ist jedoch nicht privat. Mit dieser AssignMessage-Richtlinie wird eine private Variable aus der Attributsatzvariablen erstellt.

1. Klicken Sie im Navigationsmenü für den Proxy im Abschnitt Proxy-Endpunkte unter Standard auf PreFlow.

   Der Anfrage-PreFlow im Standard-Proxyendpunkt ist der erste Ablauf, der ausgeführt wird, wenn eine Anfrage im API-Proxy eingeht.

   Für die OAuthV2-Richtlinie ist das Secret erforderlich. Sie wird sehr früh im API-Proxy ausgeführt.

2. Klicken Sie im Bereich Ablauf im Anfrageablauf direkt neben PreFlow auf die Schaltfläche +.

3. Wählen Sie Neue Richtlinie erstellen aus. Wählen Sie im Drop-down-Menü Richtlinie auswählen im Bereich Vermittlung die Option Mitteilung zuweisen aus und legen Sie für Anzeigename und Name AM-GetSecret fest.

4. Klicken Sie auf Hinzufügen. Klicken Sie im Navigationsmenü unter Richtlinien auf AM-GetSecret.

   Die Konfiguration der AssignMessage-Richtlinie wird im Bereich Code angezeigt.

5. Ändern Sie die Richtlinienkonfiguration in:

   <AssignMessage name="AM-GetSecret"> <AssignVariable> <Name>private.secretkey</Name> <Ref>propertyset.oauth.secret</Ref> </AssignVariable> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </AssignMessage>

   Mit der Einstellung AssignVariable wird die Variable propertyset.oauth.secret in die Variable private.secretkey kopiert.

   Die Einstellung IgnoreUnresolvedVariables bewirkt, dass die AssignMessage-Richtlinie einen Fehler ausgibt, wenn propertyset.oauth.secret nicht aufgelöst werden kann.

OAuthV2-Richtlinie zum Überprüfen eines Tokens hinzufügen

1. Klicken Sie im Navigationsmenü für den Proxy im Abschnitt Proxy-Endpunkte unter Standard auf PreFlow.

   Die OAuthV2-Richtlinie sollte nach der AssignMessage-Richtlinie ausgeführt werden.

2. Klicken Sie im Bereich Ablauf im Anfrageablauf direkt neben PreFlow auf die Schaltfläche +.

3. Wählen Sie Neue Richtlinie erstellen aus. Wählen Sie im Drop-down-Menü Richtlinie auswählen im Abschnitt Sicherheit die Option OAuth v2.0 aus und legen Sie Anzeigename und Name auf OA-VerifyToken fest.

4. Klicken Sie auf Hinzufügen und dann im Navigationsmenü unter Richtlinien auf OA-VerifyToken.

   Die OAuthV2-Richtlinienkonfiguration wird im Bereich Code angezeigt.

5. Ändern Sie die Konfiguration der OAuthV2-Richtlinie in:

   <OAuthV2 name="OA-VerifyToken"> <Operation>VerifyJWTAccessToken</Operation> <Algorithm>HS256</Algorithm> <SecretKey> <Value ref="private.secretkey"/> </SecretKey> </OAuthV2>

   In der Konfiguration wird angegeben, dass für das JWT-Zugriffstoken der HS256-Algorithmus (HMAC-SHA256) verwendet wird. Als geheimer Schlüssel wird die private Variable verwendet, die in der AssignMessage-Richtlinie erstellt wurde.

6. Klicken Sie auf Speichern.

Klicken Sie auf Fortschritt prüfen. Richtlinien zum Überprüfen von Tokens hinzufügen

Aufgabe 3: Richtlinien zum Generieren von Tokens hinzufügen

Dem API-Proxy wird auch ein separater Proxy-Endpunkt hinzugefügt, damit die JWT-Tokens erstellt werden können.

Neuen Proxy-Endpunkt für Tokenvorgänge hinzufügen

In einer Produktionsumgebung wird in der Regel ein separater Proxy zum Generieren von Tokens erstellt. In diesem Lab erstellen Sie den Tokengenerierungsablauf in einem separaten Proxy-Endpunkt innerhalb desselben API-Proxys.

1. Klicken Sie im Navigationsmenü für den Proxy in der Zeile Proxy-Endpunkte auf die Schaltfläche +.

   Hinweis: Klicken Sie nicht auf die Schaltfläche „+“ neben „Standard“.

   Dadurch wird ein neuer Proxy-Endpunkt erstellt, der beim Erstellen eines neuen JWT verwendet werden soll.

2. Geben Sie für Name token an und klicken Sie dann auf Hinzufügen.

   Der neue Proxy-Endpunkt mit dem Namen token wird im Bereich Code angezeigt.

3. Ändern Sie die gesamte token-Ablaufkonfiguration von:

   <ProxyEndpoint name="token"> . . . </ProxyEndpoint>

   zu:

   <ProxyEndpoint name="token"> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <Flows/> <HTTPProxyConnection> <BasePath>/token</BasePath> </HTTPProxyConnection> <RouteRule name="noTarget"/> </ProxyEndpoint>

4. Klicken Sie auf Speichern.

   Diese aktualisierte Konfiguration führt zu zwei spezifischen Änderungen:

   • Der BasePath wird auf /token festgelegt. Dies ist der Basispfad, der beim Erstellen eines Tokens verwendet wird.
   • Die RouteRule verweist nicht mehr auf einen Zielendpunkt. Der API-Proxy erstellt ein Token, ohne den Backend-Dienst aufzurufen.

Ablauf zum Generieren eines Tokens erstellen

1. Klicken Sie im Ablauf für den Proxy im Abschnitt Proxy-Endpunkte: token direkt neben /token auf +.

2. Geben Sie für den neuen bedingten Ablauf die folgenden Werte an:

   Attribut	Wert
   Ablaufname	generateToken
   Bedingungstyp	Benutzerdefiniert auswählen

3. Geben Sie für Bedingung den folgenden Wert an:

   (proxy.pathsuffix MatchesPath "/") and (request.verb = "POST") and (request.formparam.grant_type = "client_credentials")

   Es sind nur gültige Tokenanfragen für Clientanmeldedaten zulässig.

4. Klicken Sie auf Hinzufügen.

AssignMessage-Richtlinie anhängen, um den Attributsatzwert abzurufen

Die OAuthV2-Richtlinie, mit der Tokens generiert werden, muss auch Zugriff auf die Variable „private.secretkey“ haben.

1. Klicken Sie im Navigationsmenü für den Proxy im Abschnitt Proxy-Endpunkte unter token auf generateToken.

2. Klicken Sie im Bereich Ablauf rechts neben generateToken im Anfragefluss auf die Schaltfläche +.

3. Wählen Sie unter Richtlinie auswählen die Option Vorhandene Richtlinie auswählen aus und klicken Sie dann auf AM-GetSecret.

4. Klicken Sie auf Hinzufügen.

   Dieselbe AssignMessage-Richtlinie ist an den PreFlow des Token-Proxy-Endpunkts angehängt.

OAuthV2-Richtlinie zum Generieren eines Tokens hinzufügen

1. Klicken Sie im Navigationsmenü für den Proxy im Abschnitt Proxy-Endpunkte unter token auf generateToken.

2. Klicken Sie im Bereich Ablauf rechts neben generateToken im Anfragefluss auf die Schaltfläche +.

3. Wählen Sie unter Richtlinie auswählen die Option Neue Richtlinie erstellen aus, wählen Sie im Abschnitt Sicherheit die Option OAuth v2.0 aus und legen Sie dann für Anzeigename und Name OA-GenerateToken fest.

4. Klicken Sie auf Hinzufügen und dann in den Richtlinien auf OA-GenerateToken.

   Die OAuthV2-Richtlinienkonfiguration wird im Bereich Code angezeigt.

5. Ändern Sie die Konfiguration der OAuthV2-Richtlinie in:

   <OAuthV2 name="OA-GenerateToken"> <Operation>GenerateJWTAccessToken</Operation> <Algorithm>HS256</Algorithm> <SecretKey> <Value ref="private.secretkey"/> </SecretKey> <SupportedGrantTypes> <!-- pass client_id and client_secret via basic auth header --> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <!-- 1800000 ms = 1800 s = 30 min --> <ExpiresIn>1800000</ExpiresIn> <GenerateResponse enabled="true"/> <RFCCompliantRequestResponse>true</RFCCompliantRequestResponse> </OAuthV2>

   Mit dieser Konfiguration kann ein JWT-OAuth-Token erstellt werden, das nach 30 Minuten abläuft.

Fehler für eine ungültige Tokenanfrage ausgeben

1. Klicken Sie im Ablauf für den Proxy im Abschnitt Proxy-Endpunkte: token direkt neben /token auf +.

2. Geben Sie für den neuen bedingten Ablauf die folgenden Werte an:

   Attribut	Wert
   Ablaufname	invalidRequest
   Bedingungstyp	Benutzerdefiniert auswählen
   Bedingung	DELETETHIS

   Die Bedingung wird gelöscht, sobald der Ablauf hinzugefügt wurde, da alle ungültigen „generateToken“-Anfragen diesen Ablauf durchlaufen sollten.

3. Klicken Sie auf Hinzufügen.

4. Entfernen Sie im Ablauf invalidRequest die folgende Zeile:

   <Condition>DELETETHIS</Condition>

5. Klicken Sie im Navigationsmenü für den Proxy im Abschnitt Proxy-Endpunkte unter token auf invalidRequest.

6. Klicken Sie im Bereich Ablauf direkt neben invalidRequest für den Anforderungsablauf auf die Schaltfläche +.

7. Wählen Sie Neue Richtlinie erstellen und im Bereich Vermittlung die Option Fehler ausgeben aus. Legen Sie dann Anzeigename und Name auf RF-InvalidTokenRequest fest.

8. Klicken Sie auf Hinzufügen und dann unter Richtlinien auf RF-InvalidTokenRequest.

   Die Konfiguration der RaiseFault-Richtlinie wird im Bereich Code angezeigt.

9. Ändern Sie die Konfiguration der RaiseFault-Richtlinie in:

   <RaiseFault name="RF-InvalidTokenRequest"> <FaultResponse> <Set> <StatusCode>400</StatusCode> <ReasonPhrase>Bad Request</ReasonPhrase> <Payload contentType="application/json">{ "error":"Bad request: use POST /token" }</Payload> </Set> </FaultResponse> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault>

   Wenn die Anfrage ungültig war, wird die Antwort 400 Falsche Anfrage zurückgegeben.

10. Klicken Sie auf Speichern.

Klicken Sie auf Fortschritt prüfen. Richtlinien zum Generieren von Tokens hinzufügen

Aufgabe 4: OAuth 2.0-Proxy bereitstellen

In dieser Aufgabe stellen Sie den API-Proxy bereit und bestätigen, dass für den Zugriff ein OAuth-Token erforderlich ist.

Prüfen, ob die Laufzeitinstanz verfügbar ist

1. Fügen Sie in Cloud Shell die folgenden Befehle ein und führen Sie sie aus:

   export INSTANCE_NAME=eval-instance; export ENV_NAME=eval; export PREV_INSTANCE_STATE=; echo "waiting for runtime instance ${INSTANCE_NAME} to be active"; while : ; do export INSTANCE_STATE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}" | jq "select(.state != null) | .state" --raw-output); [[ "${INSTANCE_STATE}" == "${PREV_INSTANCE_STATE}" ]] || (echo; echo "INSTANCE_STATE=${INSTANCE_STATE}"); export PREV_INSTANCE_STATE=${INSTANCE_STATE}; [[ "${INSTANCE_STATE}" != "ACTIVE" ]] || break; echo -n "."; sleep 5; done; echo; echo "instance created, waiting for environment ${ENV_NAME} to be attached to instance"; while : ; do export ATTACHMENT_DONE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}/attachments" | jq "select(.attachments != null) | .attachments[] | select(.environment == \"${ENV_NAME}\") | .environment" --join-output); [[ "${ATTACHMENT_DONE}" != "${ENV_NAME}" ]] || break; echo -n "."; sleep 5; done; echo "***ORG IS READY TO USE***";

   Diese Befehlsreihe verwendet die Apigee API, um festzustellen, wann die Apigee-Laufzeitinstanz erstellt und die Testumgebung angehängt wurde.

2. Warten Sie, bis die Instanz bereit ist.

   Wenn der Text ***ORG IS READY TO USE*** angezeigt wird, ist die Instanz bereit. Die Apigee-Organisation (org) wurde möglicherweise vor dem Start des Labs erstellt. Sie müssen also vielleicht nicht warten, bis die Instanz erstellt wird.

   Wenn Sie darauf warten, dass die Organisation bereit ist, können Sie sich über OAuth, die SpikeArrest-Richtlinie, das Maskieren und Ausblenden von Daten sowie intransparente Tokens und JWTs informieren.

API-Proxy bereitstellen

1. Rufen Sie in der Cloud Console Apigee auf.

2. Wählen Sie im linken Navigationsmenü Proxy-Entwicklung > API-Proxys aus und klicken Sie dann auf bank-v1.

3. Klicken Sie auf den Tab Entwickeln.

4. Klicken Sie auf Bereitstellen und wählen Sie für Umgebung die Option eval aus.

   Sie werden in einem Dialogfeld aufgefordert, die Bereitstellung zu bestätigen.

5. Geben Sie unter Dienstkonto die E-Mail-Adresse des Dienstkontos an:

   apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

6. Klicken Sie auf Bereitstellen und Bestätigen.

7. Klicken Sie auf den Tab Übersicht und warten Sie, bis der Bereitstellungsstatus für eval anzeigt, dass der Proxy bereitgestellt wurde.

Klicken Sie auf Fortschritt prüfen. API-Proxy erstellen

API-Proxy testen

Sie können die Testumgebung in der Apigee-Organisation über den Hostnamen eval.example.com aufrufen. Der DNS-Eintrag für diesen Hostnamen wurde in Ihrem Projekt erstellt und wird der IP-Adresse der Apigee-Laufzeitinstanz zugeordnet. Dieser DNS-Eintrag wurde in einer privaten Zone erstellt. Das heißt, er ist nur im internen Netzwerk sichtbar.

Cloud Shell befindet sich nicht im internen Netzwerk. Daher können Cloud-Shell-Befehle diesen DNS-Eintrag nicht zuordnen. Eine virtuelle Maschine (VM) in Ihrer Organisation kann auf das DNS der privaten Zone zugreifen. Eine virtuelle Maschine namens apigeex-test-vm wurde automatisch erstellt. Sie können den API-Proxy mithilfe dieser VM aufrufen.

1. Öffnen Sie in Cloud Shell eine SSH-Verbindung zu Ihrer Test-VM:

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

   Wenn Sie zur Autorisierung aufgefordert werden, klicken Sie auf Autorisieren.

2. Drücken Sie für jede in Cloud Shell gestellte Frage die Eingabetaste bzw. Return-Taste, um die Standardeingabe zu übernehmen.

   Ihre angemeldete Identität ist der Inhaber des Projekts. Daher ist eine SSH-Verbindung zu diesem Computer zulässig.

   Ihre Cloud Shell-Sitzung wird jetzt in der VM ausgeführt.

3. Rufen Sie den bereitgestellten API-Proxy bank-v1 in der Umgebung eval auf:

   curl -i -k -X GET "https://eval.example.com/bank/v1/customers"

   Die Option -k weist curl an, die Überprüfung des TLS-Zertifikats zu überspringen. In diesem Lab wird für die Apigee-Laufzeit ein selbst signiertes Zertifikat anstelle eines Zertifikats verwendet, das von einer vertrauenswürdigen Zertifizierungsstelle (CA) erstellt wurde.

   Hinweis: Sie sollten die Option -k nicht verwenden, um die Zertifikatsüberprüfung für Produktionsanwendungsfälle zu umgehen.

   Mit dieser API wird versucht, eine Liste von Kunden abzurufen. Es sollte nun eine 401 Nicht autorisiert-Antwort ähnlich dieser angezeigt werden:

   HTTP/2 401 content-type: application/json www-authenticate: Bearer realm="null",error="invalid_token",error_description="oauth.v2.InvalidAccessToken: Invalid access token" x-request-id: 99263881-d0f7-4495-b886-0253f28a2e05 content-length: 101 date: Tue, 11 Jan 2022 18:59:01 GMT via: 1.1 google {"fault":{"faultstring":"Invalid access token","detail":{"errorcode":"oauth.v2.InvalidAccessToken"}}}

   Diese Antwort gibt an, dass der API-Proxy den Zugriff auf den Backend-Dienst blockiert hat, weil das Zugriffstoken nicht angegeben wurde.

4. Geben Sie den Befehl exit ein, um die SSH-Sitzung zu beenden und zu Cloud Shell zurückzukehren.

Aufgabe 5: API-Produkt, Entwickler und Anwendung hinzufügen

In dieser Aufgabe fügen Sie ein API-Produkt hinzu, das Zugriff auf Ihre API bietet. Außerdem erstellen Sie einen Entwickler und dann eine Anwendung, die Ihrem API-Produkt zugeordnet wird.

API-Produkt erstellen

1. Rufen Sie in der Cloud Console Apigee auf.

2. Wählen Sie im linken Navigationsmenü Verteilung > API-Produkte aus.

3. Klicken Sie zum Erstellen eines neuen API-Produkts auf + Erstellen.

4. Geben Sie im Bereich Produktdetails Folgendes an:

   Attribut	Wert
   Name	bank-readonly
   Anzeigename	Bank (Lesezugriff)
   Umgebung	eval auswählen
   Zugriff	Public auswählen

   Lassen Sie Zugriffsanfragen automatisch genehmigen ausgewählt.

5. Klicken Sie unter Vorgänge auf + Vorgang hinzufügen.

   Mit Vorgängen wird angegeben, welche Anfragen in welchen API-Proxys für eine Anwendung zulässig sind, die dem API-Produkt zugeordnet ist.

   Hinweis: Achten Sie darauf, dass sich die Schaltfläche im Abschnitt „Vorgänge“ und nicht im Abschnitt „GraphQL-Vorgänge“ befindet.

6. Geben Sie Folgendes an:

   Attribut	Wert
   API-Proxy	Wählen Sie den API-Proxy „bank-v1“ aus.
   Pfad	/**
   Methoden	GET auswählen

   Der Pfadausdruck /\*\* gibt an, dass jede Anfrage, die mit dem Basispfad übereinstimmt, zulässig ist.

   In einer Produktionsumgebung können Sie jede zulässige Operation einzeln hinzufügen, anstatt diesen Platzhalter-Pfadausdruck zu verwenden.

7. Klicken Sie auf Speichern, um den Vorgang zu speichern.

8. Klicken Sie oben auf der Seite Produktdetails auf Speichern, um das API-Produkt zu speichern.

9. Kehren Sie zur Seite Verteilung > API-Produkte zurück.

   Das API-Produkt wird aufgeführt.

App-Entwickler erstellen

Bevor Sie eine App erstellen können, müssen Sie einen App-Entwickler erstellen.

1. Klicken Sie im Navigationsmenü links auf Verteilung > Entwickler.

2. Wenn Sie einen neuen App-Entwickler erstellen möchten, klicken Sie auf + Erstellen.

3. Geben Sie Folgendes an:

   Attribut	Wert
   Vorname	Joe
   Nachname	Developer
   Nutzername	joe
   E-Mail	joe@example.com

4. Klicken Sie auf Hinzufügen, um den App-Entwickler zu erstellen.

App mit Zugriff auf bank-v1 erstellen

1. Klicken Sie im linken Navigationsmenü auf Verteilung > Apps.

2. Klicken Sie auf + Erstellen, um eine neue App zu erstellen.

3. Geben Sie im Bereich App-Details Folgendes an:

   Attribut	Wert
   Name	readonly-app
   Entwickler	joe@example.com auswählen

4. Klicken Sie im Bereich Anmeldedaten auf Anmeldedaten hinzufügen > Produkte hinzufügen, wählen Sie im Drop-down-Menü Bank (Lesezugriff) aus und klicken Sie dann auf Hinzufügen.

5. Klicken Sie rechts oben auf Erstellen, um die App zu erstellen.

   Der Schlüssel und das Secret sind jetzt für die App konfiguriert.

6. Klicken Sie neben Schlüssel und Secret auf die Symbole Anzeigen.

   Für diese API ist ein OAuth-Zugriffstoken erforderlich. Der Schlüssel und das Secret werden als Anmeldedaten für die App verwendet, damit die App ein OAuth-Zugriffstoken erstellen kann.

Klicken Sie auf Fortschritt prüfen. API-Produkt hinzufügen und eine App erstellen

API testen

1. Öffnen Sie in Cloud Shell eine SSH-Verbindung zu Ihrer Test-VM:

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

   Wenn Sie zur Autorisierung aufgefordert werden, klicken Sie auf Autorisieren.

   Ihre Cloud Shell-Sitzung wird jetzt in der VM ausgeführt.

2. Führen Sie die folgenden Befehle aus, um den Consumer-Key und das Consumer-Secret für die Anwendung abzurufen:

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null); echo "PROJECT_ID=${PROJECT_ID}" export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output); echo "CONSUMER_KEY=${CONSUMER_KEY}" export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output); echo "CONSUMER_SECRET=${CONSUMER_SECRET}"

   Mit dem ersten Befehl wird die gcloud-Konfiguration gelesen, um das aktuelle Projekt abzurufen. Mit dem zweiten und dritten Befehl werden der Consumer-Key und das Consumer-Secret mit der Apigee API abgerufen. Die Anfrage wird autorisiert, weil Sie ein Zugriffstoken mit den Berechtigungen des angemeldeten Nutzers senden.

   Für den Genehmigungstyp für OAuth-Clientanmeldedaten muss die Clientanwendung den Consumer-Key und das Consumer-Secret in einem Autorisierungs-Header senden, um ein Zugriffstoken zu generieren.

3. Führen Sie den folgenden Befehl aus, um ein JWT-Zugriffstoken zu generieren:

   export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"); echo ${TOKEN_RESPONSE} export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output); echo "JWT_TOKEN=${JWT_TOKEN}"

   Mit dem ersten Befehl wird der Token-Endpunkt aufgerufen und die Antwort gespeichert. Das Token wird dann aus der JSON-Antwort extrahiert und in JWT_TOKEN gespeichert.

4. Verwenden Sie den folgenden Befehl, um eine Anfrage mit dem JWT-Token zu testen:

   curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers"

   Der API-Aufruf sollte jetzt eine Liste von Kunden zurückgeben.

   Hinweis: Wenn Sie eine Antwort erhalten, die besagt, dass „Ihr Client keine Berechtigung für die angeforderte URL hat“, prüfen Sie, ob die Audience in Schritt 1 richtig festgelegt wurde.

5. Geben Sie den Befehl exit ein, um die SSH-Sitzung zu beenden und zu Cloud Shell zurückzukehren.

Aufgabe 6: Ratenbegrenzung hinzufügen

In dieser Aufgabe fügen Sie eine SpikeArrest-Richtlinie hinzu, die die Kontingentkonfiguration des API-Produkts verwendet, um die Rate der API-Aufrufe zu begrenzen.

Die SpikeArrest-Richtlinie schützt Ihre APIs und Backends vor Trafficspitzen, indem Sie Ihnen ermöglicht, eine maximale zulässige Trafficrate anzugeben. Mit dieser Richtlinie können Sie dafür sorgen, dass Ihr Backend nicht durch Traffic überlastet wird, den es nicht verarbeiten kann.

SpikeArrest-Richtlinie für die Tokengenerierung hinzufügen

Mit dieser SpikeArrest-Richtlinie wird eine allgemeine Ratenbegrenzung für Traffic für Aufrufe der /token API festgelegt.

1. Rufen Sie in der Cloud Console Apigee auf.

2. Wählen Sie im linken Navigationsmenü Proxy-Entwicklung > API-Proxys aus und klicken Sie dann auf bank-v1.

3. Klicken Sie auf den Tab Entwickeln.

4. Klicken Sie im Navigationsmenü für den Proxy im Abschnitt Proxy-Endpunkte unter token auf PreFlow.

   Die SpikeArrest-Richtlinie sollte vor den Richtlinien für bedingte Abläufe ausgeführt werden.

5. Klicken Sie im Bereich Ablauf direkt neben PreFlow aus dem Anfrageablauf auf die Schaltfläche +.

6. Wählen Sie Neue Richtlinie erstellen und im Abschnitt Trafficverwaltung die Option Spike Arrest aus. Legen Sie dann für Anzeigename und Name SA-LimitTokenRate fest.

7. Klicken Sie auf Hinzufügen und dann im Abschnitt Richtlinien auf die SA-LimitTokenRate.

   Die Konfiguration der SpikeArrest-Richtlinie wird im Bereich Code angezeigt.

8. Ändern Sie die Konfiguration der SpikeArrest-Richtlinie in:

   <SpikeArrest name="SA-LimitTokenRate"> <Rate>5pm</Rate> <UseEffectiveCount>false</UseEffectiveCount> </SpikeArrest>

   In der Konfiguration wird angegeben, dass die maximal zulässige Rate von Anfragen 5 pro Minute beträgt. Der gesamte Traffic wird durch diese SpikeArrest-Richtlinie eingeschränkt.

   Hinweis: 5 Anfragen pro Minute werden verwendet, um das Testen zu erleichtern. Die SpikeArrest-Grenzwerte in diesem Lab sind in der Regel zu niedrig für reale Szenarien.

   Wenn UseEffectiveCount auf „false“ gesetzt ist, verwendet die SpikeArrest-Richtlinie den Token-Bucket-Algorithmus. Der Traffic wird ausgeglichen, indem die Rate in kleinere Intervalle unterteilt wird. 5 Anfragen pro Minute bedeutet 1 Anfrage pro Fünftel einer Minute oder 1 Anfrage alle 12 Sekunden. Wenn eine zweite Anfrage weniger als 12 Sekunden nach der vorherigen Anfrage bei einem Message Processor eingeht, wird sie möglicherweise abgelehnt.

SpikeArrest-Richtlinie für API-Anfragen hinzufügen

Mit dieser SpikeArrest-Richtlinie wird eine Ratenbegrenzung für den Traffic für Aufrufe der /bank/v1 API festgelegt. Die Rate wird pro Anwendung angewendet.

1. Klicken Sie im Navigationsmenü für den Proxy im Abschnitt Proxy-Endpunkte unter Standard auf PreFlow.

   Die SpikeArrest-Richtlinie sollte früh im Aufruf ausgeführt werden, aber nach der OAuthV2-Richtlinie „VerifyJWTAccessToken“, um die Rate basierend auf der Anwendung zu begrenzen.

2. Klicken Sie im Bereich Ablauf direkt neben PreFlow aus dem Anfrageablauf auf die Schaltfläche +.

3. Wählen Sie Neue Richtlinie erstellen und im Abschnitt Trafficverwaltung die Option Spike Arrest aus. Legen Sie dann für Anzeigename und Name SA-LimitRateByApp fest.

4. Klicken Sie auf Hinzufügen und dann im Bereich Richtlinien auf SA-LimitRateByApp.

   Die Konfiguration der SpikeArrest-Richtlinie wird im Bereich Code angezeigt.

5. Ändern Sie die Konfiguration der SpikeArrest-Richtlinie in:

   <SpikeArrest name="SA-LimitRateByApp"> <Rate>5pm</Rate> <Identifier ref="client_id" /> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>

   Wie bei der vorherigen Richtlinie wird in der Konfiguration angegeben, dass die maximal zulässige Rate von Anfragen 5 pro Minute beträgt. In dieser Richtlinie wird jedoch eine Kennung angegeben, mit dem die SpikeArrest-Rate für jede client_id separat verwaltet wird. Die Client-ID wird von der Richtlinie OA-VerifyToken ausgefüllt und ist für jede Entwickleranwendung eindeutig.

   Wenn UseEffectiveCount auf „true“ gesetzt ist, wird die Ratenanzahl für den gesamten Traffic innerhalb der Region beibehalten. Die Richtlinie verwaltet einen Zähler für die Anzahl der Anfragen, die pro Zeitraum empfangen werden. Bei einer Anfragerate pro Minute ist der Zeitraum eine Minute lang. Die Ratenberechnung basiert auf einem gleitenden Fenster.

   

   Angenommen, wir verwenden in diesem Beispiel eine Rate von 50 Anfragen pro Minute. Die Zähler verwenden einen Zeitraum von einer Minute. Wenn die Rate pro Sekunde angegeben worden wäre, würde der Zählerzeitraum eine Sekunde betragen. Nehmen wir an, dass wir uns 10 Sekunden in der aktuellen Minute befinden, was durch den Pfeil dargestellt wird. In der vorherigen Minute gab es 48 Anfragen und im aktuellen Zeitraum bisher 5 Anfragen.

   Damit eine weitere Anfrage möglich ist, muss die Rate unter 50 Anfragen pro Minute liegen. Die berechnete Rate ist:

   request_rate = (48 * (60-10)/60) + 6 = 46

   Da im aktuellen Zeitraum erst 10 von 60 Sekunden vergangen sind, werden die verbleibenden 50 Sekunden mit der Rate des vorherigen Zeitraums berechnet. 5/6 von 48 sind 40. Wenn eine Anfrage zulässig wäre, würde die Anzahl für den aktuellen Zeitraum 5 + 1 oder 6 betragen. Die Berechnung der Anfragerate von 46 gibt an, dass die Anfrage zulässig ist, da die Anfragerate weniger als 50 Anfragen pro Minute beträgt.

6. Klicken Sie auf Speichern > Als neue Version speichern.

7. Klicken Sie auf Bereitstellen und wählen Sie dann eval für Umgebung aus.

8. Geben Sie unter Dienstkonto die E-Mail-Adresse des Dienstkontos an:

apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

9. Klicken Sie auf Bereitstellen und Bestätigen.
10. Klicken Sie auf den Tab Übersicht und warten Sie, bis der Bereitstellungsstatus für eval anzeigt, dass der Proxy bereitgestellt wurde.

Klicken Sie auf Fortschritt prüfen. SpikeArrest-Richtlinie hinzufügen

Ratenbegrenzung testen

1. Öffnen Sie in Cloud Shell eine SSH-Verbindung zu Ihrer Test-VM:

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

   Wenn Sie zur Autorisierung aufgefordert werden, klicken Sie auf Autorisieren.

   Ihre Cloud Shell-Sitzung wird jetzt in der VM ausgeführt.

2. Führen Sie die folgenden Befehle aus, um den Consumer-Key und das Consumer-Secret für die Anwendung abzurufen:

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null); echo "PROJECT_ID=${PROJECT_ID}" export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output); echo "CONSUMER_KEY=${CONSUMER_KEY}" export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output); echo "CONSUMER_SECRET=${CONSUMER_SECRET}"

3. Generieren Sie mehrere Zugriffstokens, indem Sie den folgenden Befehl wiederholt ausführen:

   curl -i -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"

   Sie sollten schnell eine 429 Too Many Requests-Antwort erhalten, die angibt, dass die Ratenbegrenzung überschritten wurde. Da UseEffectiveCount für diese Richtlinie „false“ ist, wird der Traffic mit dem Token-Bucket-Algorithmus ausgeglichen. Sie erhalten den Spike Arrest-Verstoß wahrscheinlich vor Ihrer fünften Anfrage.

4. Führen Sie den folgenden Befehl aus, um ein JWT-Zugriffstoken zu speichern:

   export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"); echo ${TOKEN_RESPONSE} export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output); echo "JWT_TOKEN=${JWT_TOKEN}"

5. Um die SpikeArrest-Richtlinie für API-Aufrufe zu testen, senden Sie den folgenden Befehl wiederholt:

   curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers"

   UseEffectiveCount ist „true“, daher wird in dieser Richtlinie der Algorithmus für gleitende Fenster verwendet. Sie sollten fünf erfolgreiche Anfragen stellen können, bevor eine Anfrage blockiert wird.

6. Geben Sie den Befehl exit ein, um die SSH-Sitzung zu beenden und zu Cloud Shell zurückzukehren.

Aufgabe 7: Datenmaskierung

In dieser Aufgabe erstellen Sie eine Datenmaske, um bestimmte Felder in einer Debug-Sitzung auszublenden.

Debugging-Sitzung starten

Debugging ist ein Tool zur Fehlerbehebung und zum Monitoring von API-Proxys, die auf Apigee ausgeführt werden. Mit dem Debugging-Tool können Sie die Details jedes Schritts während eines API-Aufrufs untersuchen.

1. Wählen Sie im linken Navigationsmenü Proxy-Entwicklung > API-Proxys aus und klicken Sie dann auf bank-v1.

2. Klicken Sie auf den Tab Debugging.

3. Klicken Sie im Bereich Debugging-Sitzung starten auf Debugging-Sitzung starten und wählen Sie im Drop-down-Menü für die Umgebung die eval-Umgebung aus.

4. Klicken Sie auf Start.

   Es kann einige Zeit dauern, bis die Debugging-Sitzung damit beginnt, Anfragen zu erfassen.

   Hinweis: Wenn oben auf dem Bildschirm Fehlermeldungen in roten Kästen mit Beschreibungen wie „Fehler beim Abrufen von Debugging-Transaktionen“ oder „Fehler bei der Transaktionsliste für die Debugging-Sitzung“ angezeigt werden, funktioniert Ihre Debugging-Sitzung möglicherweise trotzdem korrekt.

   Sie stellen API-Anfragen und untersuchen dann die Debugging-Sitzung.

Anfrage debuggen

1. Öffnen Sie in Cloud Shell eine SSH-Verbindung zu Ihrer Test-VM:

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

   Wenn Sie zur Autorisierung aufgefordert werden, klicken Sie auf Autorisieren.

   Ihre Cloud Shell-Sitzung wird jetzt in der VM ausgeführt.

2. Führen Sie die folgenden Befehle aus, um das Token für die Anwendung abzurufen:

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null); echo "PROJECT_ID=${PROJECT_ID}" export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output); echo "CONSUMER_KEY=${CONSUMER_KEY}" export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output); echo "CONSUMER_SECRET=${CONSUMER_SECRET}" export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"); echo ${TOKEN_RESPONSE} export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output); echo "JWT_TOKEN=${JWT_TOKEN}"

3. Stellen Sie diese Anfrage an die API:

   curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers/abe@example.org/accounts"

4. Kehren Sie zur Seite der Apigee-UI zurück.

   Auf der Debugging-Seite sollten zwei Anfragen angezeigt werden: eine POST-Anfrage (zum Generieren des Tokens) und eine GET-Anfrage (zum Abrufen der Konten für einen Nutzer).

5. Klicken Sie auf die GET-Anfrage.

   Die Details der GET-Anfrage werden angezeigt.

6. Klicken Sie auf die erste Richtlinie, die AM-GetSecret-Richtlinie, mit der die Variable propertyset.oauth.secret in die Variable private.secretkey kopiert wird.

   

   In den Phasendetails wird die private Variable nicht angezeigt, da Variablen mit dem Präfix „private.“ in der Debugging-Sitzung ausgeblendet werden. Die Variable „Attribut festlegen“ enthält jedoch dieselben sensiblen Daten. Es kann daher sinnvoll sein, sie vor Nutzern zu verbergen, die Traffic debuggen.

7. Klicken Sie auf die Antwort aus dem Backend, die durch den Kreis links neben dem Fabriksymbol gekennzeichnet ist.

   

   Die Antwort enthält die Konten des Nutzers, einschließlich der Kontostände.

Debugging-Maske erstellen

1. Öffnen Sie einen neuen Tab im selben Browserfenster und rufen Sie die Apigee API-Referenz auf.

   Die Apigee API-Referenz enthält Details zu den verschiedenen API-Aufrufen, die zum Verwalten von Apigee verwendet werden können und mit denen auch Aufrufe an die Apigee API erfolgen können. Auf dieser Seite werden die API-Aufrufe für organization.environments angezeigt.

2. Scrollen Sie zum Ende der Seite und klicken Sie auf updateDebugmask.

   Mit diesem API-Aufruf wird die Debugging-Maske für die Umgebung aktualisiert.

3. Verwenden Sie im Bereich API testen für den Anfrageparameter name Folgendes:

   organizations/{{{ project_0.project_id | PROJECT }}}/environments/eval/debugmask

4. Geben Sie für den Anfragetext Folgendes ein:

   { "responseJSONPaths": [ "$[*].balance" ], "variables": [ "propertyset.oauth.secret" ] }

   Diese Nutzlast führt dazu, dass die Variable propertyset.oauth.secret maskiert wird. Außerdem wird jedes balance-Feld im Array von Objekten in der Antwortnutzlast maskiert.

5. Klicken Sie auf Ausführen.

   Wenn Sie in einem Pop-up-Fenster aufgefordert werden, Ihr Konto auszuwählen, wählen Sie das Teilnehmerkonto aus.

6. Klicken Sie auf Zulassen, damit die Seite die Kurs-Anmeldedaten verwenden kann.

Debugging-Maske testen

1. Wählen Sie in der Apigee-UI im linken Navigationsmenü Proxy-Entwicklung > API-Proxys aus und klicken Sie dann auf bank-v1.

2. Klicken Sie auf den Tab Debugging.

3. Wählen Sie im Bereich Debugging-Sitzung starten im Drop-down-Menü für die Umgebung die Option eval aus.

4. Klicken Sie auf Start.

5. Wenn die SSH-Verbindung in Cloud Shell geschlossen wurde, öffnen Sie eine SSH-Verbindung zu Ihrer Test-VM:

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

6. Rufen Sie ein Token ab und stellen Sie die API-Anfrage noch einmal:

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers/abe@example.org/accounts"

7. Kehren Sie zur Debugging-Seite in der Apigee-UI zurück und klicken Sie auf die GET-Anfrage.

8. Klicken Sie auf die Richtlinie AM-GetSecret.

   Die Variable propertyset.oauth.secret ist maskiert.

   

9. Klicken Sie für die Backend-Antwort auf Proxy-Antwort-Ablauf gestartet.

   Jedes Feld vom Typ balance wird maskiert.

   

Aufgabe 8: Fehlerbehandlung

In dieser Aufgabe erstellen Sie einen bedingten Standardablauf, um Aufrufe bestimmter Backend-Ressourcen einzuschränken, und schreiben eine Backend-Fehlermeldung neu.

API testen

1. Wenn die SSH-Verbindung in Cloud Shell geschlossen wurde, öffnen Sie eine SSH-Verbindung zu Ihrer Test-VM:

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

2. Geben Sie Y ein, um fortzufahren, und drücken Sie zweimal die EINGABETASTE, um die Passphrase leer zu lassen.

3. Rufen Sie ein Token ab und senden Sie eine GET-Anfrage an /users:

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/users"

   Der Backend-Dienst erkennt die GET /users-Anfrage nicht und gibt daher eine 404-Antwort zurück, die in etwa so aussieht:

   HTTP/2 404 x-powered-by: Express content-security-policy: default-src 'none' x-content-type-options: nosniff content-type: text/html; charset=utf-8 x-cloud-trace-context: 7e96528757cc5053ba4fc8853037b02d;o=1 date: Wed, 19 Jan 2022 01:49:53 GMT server: Google Frontend content-length: 144 x-request-id: 2d8c8002-3152-4fc2-a60b-1729dd5483d8 via: 1.1 google <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Error</title> </head> <body> <pre>Cannot GET /users</pre> </body> </html>

   Die Antwort gibt eine HTML-Nutzlast zurück, die nicht dem Format der RF-InvalidTokenRequest-Nutzlast entspricht. Außerdem kann eine Backend-Antwort sensible Daten enthalten. Aus diesen Gründen ist es empfehlenswert, Fehlerantworten von Backend-Diensten neu zu schreiben.

„404 Nicht gefunden“-Fehler neu schreiben

Mit Fehlerregeln können Sie Fehler erkennen und Fehlermeldungen neu schreiben.

Eine RaiseFault-Richtlinie wird verwendet, um die neue Antwort festzulegen.

1. Rufen Sie in der Cloud Console Apigee auf.

2. Wählen Sie im linken Navigationsmenü Proxy-Entwicklung > API-Proxys aus und klicken Sie dann auf bank-v1.

3. Klicken Sie auf den Tab Entwickeln.

4. Klicken Sie im Navigationsmenü für den Proxy neben Richtlinien auf +.

5. Wählen Sie im Bereich Vermittlung die Option Fehler ausgeben aus und legen Sie dann Anzeigename und Name auf RF-404NotFound fest.

6. Klicken Sie auf Erstellen. Klicken Sie im Abschnitt Richtlinien auf RF-404NotFound.

7. Ändern Sie die Konfiguration der RaiseFault-Richtlinie in:

   <RaiseFault name="RF-404NotFound"> <FaultResponse> <Remove> <Headers/> </Remove> <Set> <StatusCode>404</StatusCode> <ReasonPhrase>Not Found</ReasonPhrase> <Headers> <Header name="FaultName">{fault.name}</Header> </Headers> <Payload contentType="application/json">{ "error": "{request.verb} {proxy.pathsuffix} not found" }</Payload> </Set> </FaultResponse> <AssignTo createNew="true" type="response"/> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault>

   Im Abschnitt Entfernen werden zuerst alle Header entfernt, die möglicherweise vom Backend-Dienst stammen. Anschließend wird im Abschnitt Festlegen die Antwort erstellt. Der Header FaultName wurde hinzugefügt, um den Wert der Variablen fault.name anzuzeigen, wenn der Fehler ausgelöst wird. Die Variable fault.name gibt den Namen des Fehlers an.

FaultRule erstellen

1. Klicken Sie im Navigationsmenü des Proxys im Abschnitt Zielendpunkte auf Standard.

   Der Standardzielendpunkt enthält den Backend-Zielaufruf, der die 404-Antwort zurückgibt. Ein 404-Fehler wird als Fehlercode behandelt. Der Endpunkt löst einen Fehler aus und FaultRules, die im Zielendpunkt angegeben sind, können verwendet werden, um die API-Antwort neu zu schreiben.

2. Fügen Sie in der TargetEndpoint-Konfiguration direkt unter dem TargetEndpoint-Tag den folgenden FaultRules-Abschnitt ein:

   <FaultRules> <FaultRule name="404"> <Step> <Name>RF-404NotFound</Name> </Step> <Condition>response.status.code == 404</Condition> </FaultRule> </FaultRules>

   Der Anfang des TargetEndpoint sieht jetzt in etwa so aus:

   <TargetEndpoint name="default"> <FaultRules> <FaultRule name="404"> <Step> <Name>RF-404NotFound</Name> </Step> <Condition>response.status.code == 404</Condition> </FaultRule> </FaultRules>

3. Klicken Sie auf Speichern > Als neue Version speichern.

4. Klicken Sie auf Bereitstellen und wählen Sie eval für Umgebung aus.

5. Geben Sie unter Dienstkonto die E-Mail-Adresse des Dienstkontos an:

   apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

6. Klicken Sie auf Bereitstellen und dann auf Bestätigen.

7. Klicken Sie auf den Tab Übersicht und warten Sie, bis der Bereitstellungsstatus für eval anzeigt, dass der Proxy bereitgestellt wurde.

Fehler bei der Endpunktantwort testen

1. Wenn die SSH-Verbindung in Cloud Shell geschlossen wurde, öffnen Sie eine SSH-Verbindung zu Ihrer Test-VM:

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

2. Rufen Sie ein Token ab und senden Sie eine GET-Anfrage an /users:

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/users"

   Die Antwort wurde neu geschrieben und sieht jetzt in etwa so aus:

   HTTP/2 404 faultname: ErrorResponseCode content-type: application/json x-request-id: 8d9db301-b3c7-4957-816d-93e796306dfb content-length: 39 date: Tue, 18 Jan 2022 06:42:23 GMT via: 1.1 google { "error": "GET /users not found" }

   Die Antwort verwendet jetzt JSON. Der Header faultname hat den Wert ErrorResponseCode. Das ist der Wert der Variablen fault.name, die angegeben wird, wenn das Ziel einen Fehlercode zurückgibt. Sobald die 404-Antwort vom Backend-Dienst zurückkam, wurde ein Fehler ausgelöst und die Fehlerregeln des Zielendpunkts wurden ausgewertet. Die 404-Fehlerregel hat die Antwort dann neu geschrieben.

Bedingten 404-Ablauf hinzufügen

Anstatt davon auszugehen, dass das Backend eine Antwort zurückgibt, wenn eine unerwartete Anfrage gesendet wird, kann am Ende der bedingten Abläufe des Proxy-Endpunkts ein neuer bedingter Ablauf hinzugefügt werden, um einen Fehler auszulösen, wenn keine der anderen bedingten Abläufe ihren Bedingungen entspricht. So wird sichergestellt, dass nur die in den bedingten Abläufen aufgeführten Vorgänge an das Backend weitergeleitet werden. Mit diesem Muster können Sie den Zugriff nur auf eine Teilmenge der Backend-Dienstressourcen zulassen.

1. Rufen Sie im Navigationsmenü für den Proxy Proxy-Endpunkt: Standard auf und klicken Sie dann im Abschnitt „Ablauf“ neben /bank/v1 auf +.

2. Geben Sie für den neuen bedingten Ablauf die folgenden Werte an:

   Attribut	Wert
   Ablaufname	404NotFound
   Bedingungstyp	Benutzerdefiniert auswählen
   Bedingung	DELETETHIS

3. Klicken Sie auf Hinzufügen.

4. Entfernen Sie im Ablauf 404NotFound die folgende Zeile:

   <Condition>DELETETHIS</Condition>

   Wenn die Bedingungen für alle vorherigen bedingten Abläufe nicht übereinstimmen, wird der Ablauf 404NotFound ausgeführt.

5. Klicken Sie im Navigationsmenü für den Proxy im Abschnitt Proxy-Endpunkte unter Standard auf 404NotFound.

6. Klicken Sie im Bereich Ablauf direkt neben dem Anfrageablauf 404NotFound auf die Schaltfläche +.

7. Wählen Sie unter Richtlinie auswählen die Option Vorhandene Richtlinie auswählen aus und klicken Sie dann auf RF-404NotFound.

8. Klicken Sie auf Hinzufügen.

9. Wählen Sie Speichern > Als neue Version speichern aus.

10. Klicken Sie auf Bereitstellen und wählen Sie dann eval für Umgebung aus.

11. Geben Sie unter Dienstkonto die E-Mail-Adresse des Dienstkontos an:

    apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

12. Klicken Sie auf Bereitstellen und dann auf Bestätigen.

13. Klicken Sie auf den Tab Übersicht und warten Sie, bis der Bereitstellungsstatus für eval anzeigt, dass der Proxy bereitgestellt wurde.

Klicken Sie auf Fortschritt prüfen. Fehlerbehandlung hinzufügen

Bedingten 404-Ablauf testen

1. Wenn die SSH-Verbindung in Cloud Shell geschlossen wurde, öffnen Sie eine SSH-Verbindung zu Ihrer Test-VM:

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

2. Rufen Sie ein Token ab und senden Sie eine GET-Anfrage an /users:

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/users"

   Die Antwort wurde neu geschrieben und sieht jetzt in etwa so aus:

   HTTP/2 404 faultname: RaiseFault content-type: application/json x-request-id: d6bbd48f-65bd-4551-9236-636fad03a609 content-length: 39 date: Tue, 18 Jan 2022 07:07:58 GMT via: 1.1 google alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 { "error": "GET /users not found" }

   Der Header faultname hat jetzt den Wert RaiseFault. Das ist der Wert von fault.name, der verwendet wird, wenn ein Fehler durch eine RaiseFault-Richtlinie ausgelöst wurde. Die RaiseFault-Richtlinie im bedingten 404NotFound-Ablauf hat die Antwort generiert.

Glückwunsch!

In diesem Lab haben Sie eine API durch die Anforderung eines JWT-OAuth-Tokens geschützt. Sie haben den Traffic durch Hinzufügen von SpikeArrest-Richtlinien eingeschränkt. Sie haben private Variablen und Datenmaskierung verwendet, um sensible Daten in Debugging-Sitzungen auszublenden. Sie haben auch eine Backend-Fehlermeldung neu geschrieben und einen bedingten 404-Ablauf verwendet, um Aufrufe des Backends auf bestimmte Ressourcen zu beschränken.

Weitere Informationen

• OAuth
• SpikeArrest-Richtlinie
• Daten maskieren und ausblenden
• Intransparente Tokens und JWTs
• Fehlerbehebung

Anleitung zuletzt am 6. August 2025 aktualisiert

Lab zuletzt am 6. August 2025 getestet

© 2026 Google LLC. Alle Rechte vorbehalten. Google und das Google-Logo sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen können Marken der jeweils mit ihnen verbundenen Unternehmen sein.