WP REST-API Einrichten und Verwenden der OAuth 1.0a-Authentifizierung

Im vorherigen Teil der Serie haben wir die grundlegende HTTP-Authentifizierung auf dem Server eingerichtet, indem wir das Plug-in für GitHub vom WP REST API-Team installieren. Die grundlegende Authentifizierungsmethode ermöglicht das Senden authentifizierter Anforderungen, indem Anmeldeinformationen im Anforderungsheader gesendet werden. Obwohl sie schnell und praktisch sind, besteht die Möglichkeit, dass diese Anmeldeinformationen in die falschen Hände geraten. Daher sollte diese Methode nur in sicheren Netzwerken nur für Entwicklungs- und Testzwecke verwendet werden.

Für die Verwendung der Authentifizierung auf Produktionsservern muss es sicherer sein, authentifizierte Anforderungen zu senden, ohne die Anmeldeinformationen preiszugeben. Dank der OAuth-Authentifizierungsmethode können diese Anforderungen gesendet werden, ohne dass der Benutzername und das Kennwort auf unsichere Weise offengelegt werden.

Im aktuellen Teil der Serie lernen wir, die OAuth-Authentifizierungsmethode für das WP REST-API-Plugin einzurichten und zu verwenden. Um genau zu sein, werden wir:

  • Machen Sie sich einen Überblick über die OAuth-Authentifizierungsmethode und deren Funktionsweise
  • Installieren Sie das OAuth-Server-Plugin
  • Generieren Sie ein OAuth-Zugriffstoken, das in unserer App verwendet werden soll

Beginnen wir mit der OAuth-Authentifizierungsmethode.

Einführung in die OAuth-Authentifizierung

Was machen Sie, wenn Sie sich bei Ihrem WordPress-Administrator anmelden müssen? Gehen Sie einfach auf die Anmeldeseite und geben Sie Ihre Anmeldeinformationen ein, oder? Das ist einfach! Was aber, wenn Sie einen Dienst eines Drittanbieters verwenden, der Zugriff auf Ihre WordPress-Ressourcen (Posts, Seiten, Medien oder etwas anderes) erfordert? Würden Sie einfach Ihre Anmeldeinformationen an diesen Dienst übergeben und wissen, dass sie in falsche Hände geraten könnten, wenn die Integrität dieses Dienstes beeinträchtigt wird? Die Antwort wäre wahrscheinlich "Nein".

Im traditionellen Authentifizierungsmodell gibt es zwei Rollen:

  1. Der Kunde: kann ein Benutzer, eine Anwendung oder ein Dienst sein
  2. Der Ressourcenanbieter: der Server, auf dem sich die geschützten Ressourcen befinden

Wenn ein Client auf geschützte Ressourcen zugreifen möchte, wird er authentifiziert, indem er dem Server die entsprechenden Anmeldeinformationen bereitstellt, und er erhält Zugriff.

Das Problem tritt auf, wenn ein Dienst eines Drittanbieters Zugriff auf diese geschützten Ressourcen auf dem Server benötigt. Dieser Service kann nicht sein (und sollte Anmeldeinformationen nicht vom Benutzer erteilt werden, um auf Ressourcen zuzugreifen. Wenn Sie Anmeldeinformationen an Dritte weitergeben, geben Sie die vollständige Kontrolle über die auf dem Server befindliche Ressource. 

Hier kommt die OAuth-Authentifizierungsmethode zur Rettung. Es führt eine neue Rolle in den Authentifizierungsprozess ein, und es ist die Ressourcenbesitzer. Nun gibt es drei Rollen im Authentifizierungsprozess:

  1. Der Kunde: Nicht der Benutzer selbst, sondern eine Anwendung oder ein Dienst eines Drittanbieters, der im Auftrag des Benutzers handelt und auf geschützte Ressourcen zugreift
  2. Der Server: der Server, auf dem sich die geschützten Ressourcen befinden
  3. Der Besitzer der Ressource: der Benutzer selbst

Die oben genannten drei Rollen bilden zusammen die so genannte dreibeinige OAuth-Authentifizierung. Die Anzahl der Zweige definiert die Rollen, die an einem Authentifizierungsprozess beteiligt sind. Wenn der Ressourcenbesitzer auch der Client ist, wird der Fluss als zweibeinige Authentifizierung bezeichnet.

Laut Webopedia:

OAuth ist ein offener Autorisierungsstandard, der den sicheren Zugriff der Clientanwendungen auf Serverressourcen ermöglicht. Das OAuth-Berechtigungsframework ermöglicht einer Drittanbieteranwendung den eingeschränkten Zugriff auf einen HTTP-Dienst, entweder im Namen eines Ressourceneigners oder indem der Drittanbieteranwendung der Zugriff auf ihren eigenen Namen ermöglicht wird.
OAuth ermöglicht Serverbesitzern, den Zugriff auf die Serverressourcen zu autorisieren, ohne die Berechtigungsnachweise gemeinsam zu nutzen. Dies bedeutet, dass der Benutzer Zugriff auf private Ressourcen von einem Server zu einer anderen Serverressource gewähren kann, ohne deren Identität zu teilen.

Daher muss der Benutzer im OAuth-Authentifizierungsablauf keine Anmeldeinformationen preisgeben, sondern kann den Client autorisieren, in seinem Namen zu handeln, um zu entscheiden, auf welche Ressourcen der Client zugreifen kann. Mit anderen Worten, der Benutzer kann zwar keine Anmeldeinformationen angeben, er kann jedoch auch festlegen, welchen Zugriff der Client erhält.

Dadurch können nicht nur Websites, sondern auch Desktop- und mobile Anwendungen eingeschränkten Zugriff auf eine Ressource auf einem Server erhalten.

In Bezug auf WordPress informiert OAuth den Ressourcenanbieter (die WordPress-Installation), dass der Ressourcenbesitzer (der WordPress-Benutzer) die Berechtigung zum Zugriff auf eine Drittanbieteranwendung zum Zugriff auf seine Ressourcen erteilt hat. Diese Ressourcen können wie Posts, Seiten, Taxonomie und Medien usw. sein. Diese Berechtigung kann für einen eingeschränkten oder vollständigen Zugriff sein, wie wir später in diesem Lernprogramm sehen werden.

So funktioniert der OAuth-Authentifizierungsablauf

Die OAuth-Authentifizierungs-API für WordPress basiert auf den Spezifikationen von OAuth 1.0a. Daher werden wir einen Blick auf die Funktionsweise von OAuth 1.0a werfen.

OAuth verwendet Token-Berechtigungsnachweise, die vom Ressourcenanbieter (Server) auf Anforderung des Ressourcenbesitzers ausgegeben werden, nachdem er sich anhand seiner Berechtigungsnachweise authentifiziert hat. Diese mit dem Ressourceninhaber verknüpften Token werden dann vom Client (einer Anwendung oder einem Dienst eines Drittanbieters) verwendet, um Zugriff auf geschützte Ressourcen zu erhalten.

Diese Token-Anmeldeinformationen haben eine begrenzte Lebensdauer und können vom Server auf Anforderung des Ressourcenbesitzers gesperrt werden.

Der OAuth-Fluss sieht folgendermaßen aus:

  1. Der Client sendet eine signierte Anfrage an den Server, um eine Token anfordern, auch bekannt als Vorläufige Anmeldeinformationen. Diese Anfrage wird an den gesendet Vorläufige Anmeldeinformationen Endpunkt-URI, und es enthält Folgendes:
    • oauth_consumer_key: vom Server bereitgestellt
    • oauth_timestamp
    • oauth_nonce
    • oauth_signature
    • oauth_signature_method
    • oath_callback
    • oauth_version (wahlweise)
  2. Der Server überprüft die Anforderung und gewährt, sofern sie gültig ist, ein Anfragetoken, das Folgendes enthält:
    • oauth_token
    • oauth_token_secret
    • oauth_callback_confirmed
  3. Der Client sendet dann den Ressourcenbesitzer (den Benutzer) an den Server, um die Anforderung zu autorisieren. Dies geschieht durch Erstellen einer Anforderungs-URI durch Hinzufügen oauth_token im vorherigen Schritt an den Ressourcen-Endpunkt der Ressourceneigentümerberechtigung abgerufen.
  4. Der Ressourceneigentümer (der Benutzer) autorisiert den Server, indem er Anmeldeinformationen bereitstellt.
  5. Wenn die oauth_callback Der URI wurde im ersten Schritt bereitgestellt. Der Server leitet den Client an diesen URI weiter und fügt den folgenden Code als Abfragezeichenfolge an:
    • oauth_token: im zweiten Schritt erhalten
    • oauth_verifier: Wird verwendet, um sicherzustellen, dass der Ressourceninhaber, der Zugriff gewährt hat, derselbe an den Client zurückgegeben wird
  6. Wenn die oauth_callback Im ersten Schritt wurde keine URI angegeben. Anschließend zeigt der Server den Wert von an oauth_verifier so dass der Ressourcenbesitzer den Client manuell informieren kann.
  7. Nach Erhalt oauth_verfier, Der Client fordert den Server nach Tokenanmeldeinformationen an, indem er eine Anforderung an den Endpunkt-URI des Tokenanforderungspunkts sendet. Diese Anfrage enthält Folgendes:
    • oauth_token: im zweiten Schritt erhalten
    • oauth_verfier: im vorherigen Schritt erhalten
    • oauth_consumer_key: Wird vom Ressourcenanbieter (dem Server) bereitgestellt, bevor der oauth Handshake gestartet wird
    • oauth_signature
    • oauth_signature_method
    • oauth_nonce
    • oauth_version
  8. Der Server überprüft die Anforderung und erteilt Folgendes: Token-Berechtigungsnachweise:
    • oauth_token
    • oauth_token_secret
  9. Der Client verwendet dann Token-Berechtigungsnachweise, um auf geschützte Ressourcen auf dem Server zuzugreifen.

Die oben genannten Informationen können entweder mit einer zur Anforderung von URIs angehängten Abfragezeichenfolge transportiert werden oder durch Einfügen in die Genehmigung Header, obwohl letzteres aufgrund der besseren Sicherheit empfohlen wird.

Dies ist ein langwieriger Prozess und sollte bei der Entwicklung unserer eigenen Kunden für die Interaktion mit der API berücksichtigt werden. Der Zweck des Clients besteht darin, all diesen Jargon zu verwalten und dem Benutzer den Authentifizierungsprozess zu erleichtern. Da wir ein vom WP REST API-Team bereitgestelltes Paket verwenden werden, werden die oben genannten Details entfernt und wir können in nur wenigen Schritten Token-Anmeldeinformationen abrufen.

In der obigen Diskussion stießen wir auf drei Endpunkt-URIs:

  1. Endpunkt für temporäre Anmeldeinformationen
  2. Berechtigungsendpunkt für Ressourcenbesitzer
  3. Token-Anmeldeinformationen Anforderungsendpunkt

Diese URIs werden vom Server auf verschiedene Arten bereitgestellt. Eine dieser Möglichkeiten besteht darin, sie bei der Überprüfung der API in der Serverantwort anzuzeigen. Die OAuth-Authentifizierungs-API für die WordPress-REST-API verwendet dieselbe Methode, wie wir im nächsten Abschnitt sehen werden.

Nachdem wir die Funktionsweise von OAuth untersucht haben, müssen Sie als Nächstes die OAuth-Authentifizierungs-API für WordPress installieren und aktivieren.

Installieren der OAuth-Authentifizierungs-API für WordPress

Mit der OAuth-Authentifizierungs-API für WordPress kann der Server authentifizierte Anforderungen mithilfe der OAuth-Implementierung annehmen. Es basiert auf den OAuth 1.0a-Spezifikationen und erweitert diese um einen zusätzlichen Parameter-wp_scope-an die gesendet werden Vorläufige Anmeldeinformationsanfrage Endpunkt. Das wp_scope Parameter definiert den Umfang des Zugriffs, der dem Client gewährt wird. Mehr dazu finden Sie in der offiziellen Dokumentation zu GitHub.

Das Plugin ist auf Github vom WP REST API-Team verfügbar und unterstützt nur Version 4.4 oder höher von WordPress.

Lassen Sie uns das Plugin klonen, indem Sie zu der / wp-content / plugins / Verzeichnis:

$ git clone https://github.com/WP-API/OAuth1.git

Aktivieren Sie nach dem Download das Plugin mit WP CLI:

$ wp plugin aktiviert OAuth1

Alternativ können Sie es auch aktivieren, indem Sie mit Ihrem Browser zu den WordPress-Plugins für Administratoren navigieren, wenn Sie WP CLI nicht verwenden möchten.

Dies ist alles, was erforderlich ist, damit der Server OAuth als Autorisierungsmethode akzeptiert. Als nächstes müssen wir eine Anfrage an den Server senden, um zu prüfen, ob die OAuth-API zur Verwendung bereit ist.

Bewerten der Verfügbarkeit der OAuth-API

Bevor wir den OAuth-Handshake initiieren, sollten wir zunächst prüfen, ob die API auf dem Server aktiviert ist. Dies geschieht durch Senden einer einfachen ERHALTEN Anfrage an die/ wp-json / Endpunkt und analysiert dann die vom Server gesendete Antwort.

Starten Sie Ihren HTTP-Client und senden Sie eine Anfrage an / wp-json / Endpunkt wie folgt:

GET http: // dein-dev-server / wp-json /

Dies gibt eine JSON-Antwort wie folgt zurück:

Unser Fokus liegt hier auf dem oauth1 Wert in der Authentifizierung Eigentumswert. Für dieses Objekt sind folgende Eigenschaften definiert:

  • anfordern: Der Endpunkt der Anforderung für temporäre Anmeldeinformationen
  • genehmigen: der Endbenutzer-Autorisierungsendpunkt
  • Zugriff: Der Endpunkt der Tokenanforderung
  • Ausführung: Die verwendete Version von OAuth

Die ersten drei davon sind absolute URLs, auf die wir gestoßen sind, als wir in einem vorherigen Abschnitt den OAuth-Mechanismus kennengelernt haben.

Das oauth1 Objekt definiert in der Authentifizierung Der Eigenschaftswert zeigt an, dass die OAuth-API für unsere WordPress-Site erfolgreich aktiviert wurde und wir sie verwenden können.

Wenn die OAuth-API für einen Standort nicht aktiviert ist, enthält die Serverantwort ein leeres Feld Genehmigung Eigenschaftswert wie folgt:

Nun, da wir das OAuth1.0a-Plugin installiert haben, wollen wir sehen, wie wir Konsumenten für unsere Anwendungen erstellen und verwalten können.

Anwendungen erstellen und verwalten

Sobald das OAuth1.0-Plugin erfolgreich installiert wurde, können wir Konsumenten für unsere Anwendungen erstellen und verwalten, indem Sie zum WordPress-Administrator und anschließend zum Benutzer> Anwendungen Seite.

Auf diese Registrierte Anwendungen Auf dieser Seite können Sie eine neue Anwendung registrieren, indem Sie auf die Schaltfläche Neu hinzufügen klicken und dann die folgenden drei Felder auf der Ergebnisseite ausfüllen:

  1. Name des Verbrauchers: Der Name des Verbrauchers. Dieser Name wird dem Benutzer während des Autorisierungsvorgangs und anschließend auf seinen Profilseiten unter angezeigt Autorisierte Anwendungen Sektion.
  2. Beschreibung: Die optionale Beschreibung für die Consumer-Anwendung.
  3. Rückruf-URL: Die Rückruf-URL. Diese Callback-URL wird beim Generieren temporärer Anmeldeinformationen verwendet, wie im nächsten Schritt gezeigt wird.

Einmal erstellt durch Klicken auf Verbraucher speichern Taste, die Kundenschlüssel und Kundengeheimnis Die Parameter werden für diesen bestimmten Verbraucher am unteren Rand der Seite angezeigt.

Diese Kundenschlüssel und Kundengeheimnis Parameter fungieren als oauth_consumer_key und oauth_consumer_secret Parameter jeweils.

Neu Kundengeheimnis kann durch Anklicken von erstellt werden Geheimnis regenerieren Schaltfläche am unteren Rand der Seite.

Das OAuth-Plugin bietet auch die Funktionalität zum Erstellen eines Konsumenten in der Konsole über das WP CLI-Plugin. So kann ein neuer Verbraucher auch mit dem folgenden Befehl im Terminal erstellt werden:

wp oauth1 add --name = --beschreibung =

Dieser neu erstellte Verbraucher erscheint dann auf der Registrierte Anwendungen Seite, wo Sie es bearbeiten können.

Nachdem wir unsere Bewerbung registriert haben, können wir in den folgenden Abschnitten den OAuth-Autorisierungsprozess starten.

Client-CLI-Paket installieren

Bitte beachten Sie, dass das OAuth1.0a-Plugin zum Zeitpunkt der Erstellung dieses Lernprogramms das Client-CLI-Paket nicht mehr unterstützt. Das Client-CLI-Paket wird möglicherweise in naher Zukunft aktualisiert, um mit der neuesten Version des OAuth-Plugins zu arbeiten. Im Moment lesen Sie bitte den nächsten Abschnitt zum Generieren von OAuth-Berechtigungsnachweisen mithilfe eines HTTP-Clients.

Das Client-CLI-Paket des WP REST-API-Teams ermöglicht die Remote-Interaktion mit einer WordPress-Site mithilfe von WP-CLI und WP REST-API. Die Quelle ist auf GitHub zu finden.

Um dieses Paket verwenden zu können, müssen Sie Folgendes auf dem Server, auf dem sich Ihre WordPress-Installation befindet, installieren und aktivieren:

  1. WP CLI
  2. WP REST API-Plugin
  3. OAuth 1.0a Server Plugin

Auf dem Computer (oder Client), von dem aus Sie Anforderungen generieren möchten, muss Folgendes installiert sein:

  1. WP CLI
  2. Komponist
  3. Das Client-CLI-Repository selbst

Die Anweisungen zum Installieren der obigen Pakete finden Sie auf den jeweiligen Sites.

Nachdem dies gesagt wurde, klonen wir das Repository auf dem Client, indem Sie den folgenden Befehl ausführen:

$ git clone https://github.com/WP-API/client-cli

Navigieren Sie nun in das geklonte Verzeichnis und installieren Sie Paketabhängigkeiten mit Composer:

$ cd client-cli $ composer installieren

Wenn alles gut geht, sollte die Befehlszeile etwas Ähnliches anzeigen:

Nachdem wir das Paket installiert haben, können wir Token-Anmeldeinformationen generieren und mit OAuth remote mit der WordPress-REST-API interagieren.

Verwenden der Client-CLI zum Generieren von OAuth-Anmeldeinformationen

Um den OAuth-Autorisierungsprozess zu starten, erhalten wir zunächst vom Server Folgendes:

  • oauth_consumer_key
  • oauth_consumer_secret

Dies kann generiert werden, indem das Terminal zu Ihrem WordPress-Installationsverzeichnis auf dem Server geleitet wird und der folgende WP-CLI-Befehl ausgeführt wird:

$ wp oauth1 add

Dies erzeugt eine Ausgabe wie die folgende:

Das Schlüssel und Geheimnis hier erhalten sind die oauth_consumer_key und oauth_consumer_secret beziehungsweise.

Nun müssen wir den Client mit unserer WordPress-Site verknüpfen. Navigieren Sie auf dem Client zu Client-Cli Verzeichnis, das Sie im vorherigen Abschnitt geklont haben, und führen Sie den folgenden Befehl aus:

$ wp --require = client.php api oauth1 verbinden http: // ihr-dev-server / --key = --geheim =

Ersetzen Sie die URL sowie den Schlüssel und das Geheimnis, die Sie im vorherigen Schritt des obigen Befehls erhalten haben. Die Ausgabe sollte wie folgt aussehen:

$ wp --require = client.php api oauth1 verbinden http: // localserver / wordpress-api / --key = kXZZTT3O5hBZ --secret = ueDNeCfgNuyNyxkiU3qHGgWZWmGsg5lZwmMyyjANyYgz3l oauth_token = wFxrd8OzcIL6lSRkLmmvViIe Geben Sie den Bestätigungscode ein:

Navigieren Sie zu der vom Server angegebenen URL und authentifizieren Sie sich, indem Sie auf klicken Genehmigen Taste:

Sie erhalten das Bestätigungstoken (oder das oauth_verifier) auf dem nächsten Bildschirm:

Kopieren Sie den Verifier und fügen Sie ihn in Ihr Terminal ein. Sie erhalten eine Schlüssel und ein Geheimnis, welche sind im Grunde deine oauth_token und oauth_token_secret beziehungsweise:

Sie können diese Token-Anmeldeinformationen in Ihrem HTTP-Client oder in einer anderen Anwendung verwenden, die das Senden authentifizierter Anforderungen mithilfe der OAuth-API unterstützt.

Verwenden eines HTTP-Clients zum Generieren von OAuth-Anmeldeinformationen

Da das Server-Plugin von OAuth 1.0a dem dreigliedrigen Ablauf folgt, sind für das Generieren von OAuth-Berechtigungsnachweisen drei Schritte erforderlich:

  1. Erwerb temporärer Berechtigungsnachweise
  2. Benutzerberechtigungen
  3. Token-Austausch

Beginnen wir mit der Implementierung jedes der obigen Schritte unter Verwendung eines HTTP-Clients, d. H. Postman.

1. Temporäre Anmeldeinformationen erwerben

Um temporäre Anmeldeinformationen zu erhalten, senden wir eine POST Anfrage an die / oauth1 / anfrage Endpunkt. Dieser Endpunkt für temporäre Berechtigungsnachweise sollte automatisch erkannt werden, da ein Server diese Route durch eine eigene Route ersetzen kann. Wir haben uns die Funktion der automatischen Erkennung angesehen, während wir in einem vorherigen Abschnitt die Verfügbarkeit der OAuth-API beurteilten.

Das POST Anfrage sollte die oauth_consumer_key und oauth_consumer_secret Parameter, die bei der Registrierung eines Verbrauchers für die Anwendung erfasst werden. Die Anfrage kann auch die oauth_callback Der Parameter und diese Callback-URL sollten mit dem Schema, dem Host, dem Port und dem Pfad der Callback-URL übereinstimmen, die bei der Registrierung der Anwendung angegeben wurde.

Neben dem oauth_consumer_key und oauth_consumer_secret Parameter sollte die Anforderung auch die enthalten oauth_signature und oauth_signature_method Parameter. Wenn Sie Postman verwenden, wird der oauth_signature wird automatisch generiert und muss nur angegeben werden oauth_signature_method Parameter. Derzeit nur die HMAC-SHA1 Die Signaturmethode wird vom OAuth-Server-Plugin unterstützt.

Die obigen Parameter können auf drei verschiedene Arten übergeben werden:

  1. Über Genehmigung Header
  2. Via (ERHALTEN) Abfrageparameter in der URL
  3. Via (POST) fordern Sie Körperparameter an. Der Inhaltstyp sollte in diesem Fall sein application / x-www-form-urlencoded.

Sie müssen eine der oben genannten Methoden verwenden, um diese Parameter an den Server zu senden.

Beginnen wir nun mit dem Vorgang, indem Sie den Postman starten und eine E-Mail senden POST Anforderung an den Endpunkt für temporäre Berechtigungsnachweise. Aber vorher kopieren Sie die Consumer Key und Consumer Secret Parameter, die von der neu registrierten Anwendung bereitgestellt werden, da sie in diesem Schritt benötigt werden.

Konfigurieren Sie Postman zum Senden einer POST Anforderung an Ihren Endpunkt für temporäre Token-Anmeldeinformationen. Dann in der Genehmigung Wählen Sie die Registerkarte aus OAuth 1.0 Option aus der Dropdown-Liste. Füllen Sie das aus Consumer Key und Consumer Secret Felder mit den vom Verbraucher angegebenen Werten. Stellen Sie sicher, dass die Signaturmethode Option ist auf gesetzt HMAC-SHA1.

Wir müssen keine anderen Werte als diese eingeben. Drücke den Aktualisierungsanfrage Klicken Sie auf die Schaltfläche Senden Taste.

Wenn kein Fehler vorliegt, gibt der Server a zurück 200 - OK Statuscode zusammen mit dem Antworttextkörper mit dem Inhaltstyp application / x-www-form-urlencoded. Dieser Anforderungstext sieht in etwa wie die folgende Textzeichenfolge aus:

oauth_token = tyNCKaL3WAJXib5SI6jCnr4P & oauth_token_secret = 1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF & oauth_callback_confirmed =

Dieser Antwortkörper enthält drei Parameter für den nächsten Schritt des dreibeinigen Flusses. Diese drei Parameter sind:

  1. oauth_token: Ein temporäres OAuth-Token für den Autorisierungsschritt.
  2. oauth_token_secret: Ein vorübergehendes Geheimnis, das zusammen verwendet werden soll oauth_token.
  3. oauth_callback_confirmed: Dieser Parameter wird immer zurückgegeben, unabhängig davon, ob Sie das angeben oauth_callback Parameter im ersten Schritt.

Mit diesen temporären Anmeldeinformationen sind wir bereit für den Schritt der Benutzerautorisierung.

2. Benutzerberechtigung

Für den Benutzerautorisierungsschritt öffnen wir den Autorisierungsendpunkt des Ressourcenbesitzers im Browser und übergeben den oauth_token und oauth_token_secret wie im vorherigen Schritt als Abfrageparameter wie folgt erhalten:

http: // ihr-dev-server / oauth1 / autorize? oauth_token =& oauth_token_secret =

Der Browser fordert Sie auf, sich bei WordPress anzumelden (falls Sie nicht bereits angemeldet sind) und fordert Sie dann auf, die Anwendung zu autorisieren:

Hier Tolle Anwendung ist der Name der registrierten Anwendung.

Autorisieren Sie die Anwendung, indem Sie auf klicken Genehmigen und auf dem nächsten Bildschirm wird ein Bestätigungstoken angezeigt:

Dieses Token fungiert als oauth_verifier Token im nächsten Schritt.

Sobald der Benutzer den Client autorisiert hat, wird die Anwendung unter angezeigt Autorisierte Anwendungen Abschnitt über die Benutzer> Ihr Profil Seite.

3. Token-Austausch

Der nächste und der letzte Schritt im dreibeinigen Fluss ist der Token-Austausch. In diesem Schritt werden die im ersten Schritt erhaltenen temporären Token gegen ein langlebiges Token ausgetauscht, das vom Client verwendet werden kann.

Um den Tokenaustauschprozess zu initiieren, wechseln Sie zurück zu Postman und konfigurieren Sie ihn so, dass er eine POST Anforderung an den Token-Anforderungsendpunkt.

Mit der OAuth 1.0 Option erneut in der Genehmigung Tab, füllen Sie die Felder für aus Consumer Key und Consumer Secret mit den vom Verbraucher angegebenen Werten. Für die Zeichen und Token Secret Felder verwenden, verwenden Sie die Werte der oauth_token und oauth_token_secret Parameter (temporäre Berechtigungsnachweise), die im ersten Schritt erhalten wurden.

Da wir auch Parameter in der URL als Abfrageparameter übergeben können, hängen Sie das an oauth_verifier Parameter an die URL wie folgt:

http: // ihr-dev-server / oauth1 / access? oauth_verifier =

Senden Sie die Anforderung mit allen Parametern, indem Sie auf klicken Senden Taste. Wenn alles gut geht, gibt der Server eine 200 - OK Statuscode zusammen mit dem Antworttext oauth_token und oauth_token_secret Parameter.

oauth_token =& oauth_token_secret =

Zu diesem Zeitpunkt werden die im ersten Schritt erfassten temporären Token verworfen und können nicht mehr verwendet werden.

Diese neuen oauth_token und oauth_token_secret Parameter sind Ihre OAuth-Anmeldeinformationen, die Sie in Ihrem Client zum Generieren authentifizierter Anforderungen verwenden können.

Senden einer authentifizierten Testanforderung

Nun, da wir unsere Token-Anmeldeinformationen erhalten haben, können wir eine Testanfrage mit Postman an den Server senden, um zu sehen, ob sie funktionieren (natürlich tun sie das!)..

Wir senden ein LÖSCHEN Bitte an den Server, einen Beitrag mit der ID 50 zu löschen. Diese ID kann in deinem Fall anders sein.

Bevor Sie beginnen, müssen Sie Folgendes haben:

  • oauth_consumer_key: im ersten Schritt erhalten
  • oauth_consumer_secret: im ersten Schritt erhalten
  • oauth_token: im letzten Schritt erhalten
  • oauth_token_secret: im letzten Schritt erhalten

Wählen OAuth 1.0 aus der Dropdown-Liste unter Genehmigung Registerkarte Postman, und füllen Sie die ersten vier Felder wie oben beschrieben aus. Nachfolgend sieht es aus:

Drücke den Aktualisierungsanfrage Schaltfläche nach dem Ausfüllen der Felder. Überprüfen der Fügen Sie dem Header Params hinzu Option sendet die Parameter im Header der Anforderung, anstatt sie in einer Abfragezeichenfolge anzuhängen.

Senden Sie die Anfrage und Sie sollten eine 200 - OK Statuscode vom Server, der anzeigt, dass der Beitrag erfolgreich gelöscht wurde.

Fazit

In diesem ausführlichen Lernprogramm haben wir einen Überblick über die OAuth-Authentifizierungsmethode und deren Funktionsweise erhalten, um einen sicheren delegierten Zugriff auf Anwendungen und Dienste von Drittanbietern bereitzustellen. Wir haben auch die OAuth-Authentifizierungs-API für WordPress auf dem Server eingerichtet und in Verbindung mit einem HTTP-Client verwendet, um Token-Anmeldeinformationen abzurufen.

Im nächsten Teil dieser Serie werden wir uns mit dem Abrufen von Inhalten über die WP-REST-API befassen. Also bleibt gespannt…