Share
In het vorige deel van de serie hebben we de basis HTTP-authenticatie op de server ingesteld door de plug-in te installeren die beschikbaar is op GitHub door het WP REST API-team. De basisverificatiemethode stelt ons in staat om geverifieerde verzoeken te verzenden door aanmeldingsreferenties in de verzoekheader te verzenden. Hoewel het snel en handig is, bestaat er ook een kans dat deze inloggegevens in verkeerde handen vallen. Vandaar dat deze methode alleen op beveiligde netwerken mag worden gebruikt voor ontwikkeling en testdoeleinden.
Voor het gebruik van verificatie op productieservers moet er een veiligere manier zijn om geverifieerde aanvragen te verzenden zonder de aanmeldingsreferenties te riskeren. Dankzij de OAuth-authenticatiemethode kunnen die verzoeken worden verzonden zonder de gebruikersnaam en het wachtwoord op een onveilige manier bloot te leggen.
In het huidige deel van de serie zullen we leren om de OAuth-authenticatiemethode in te stellen en te gebruiken die wordt gebruikt met de WP REST API-plug-in. Om specifiek te zijn, zullen we:
Laten we beginnen met ons bekend te maken met de OAuth-authenticatiemethode.
Wat doet u wanneer u zich moet aanmelden bij uw WordPress-beheerder? U gaat eenvoudig naar de inlogpagina en voert uw inloggegevens in, toch? Dat is eenvoudig! Maar wat als u een service van derden gebruikt die toegang tot uw WordPress-bronnen vereist (berichten, pagina's, media of iets anders)? Zou u eenvoudigweg uw inloggegevens aan die dienst overhandigen, wetende dat zij in verkeerde handen terecht kunnen komen wanneer de integriteit van die dienst in het gedrang komt? Het antwoord zou waarschijnlijk "Nee" zijn.
In het traditionele authenticatiemodel zijn er twee rollen:
Als een client toegang wil tot beschermde bronnen, wordt hij of zij geverifieerd door juiste referenties aan de server te verstrekken en toegang te krijgen.
Het probleem doet zich voor wanneer een externe service toegang tot deze beschermde bronnen op de server nodig heeft. Deze service kan niet (en moeten niet) gegeven inloggegevens door de gebruiker voor toegang tot bronnen. Het verstrekken van referenties aan een derde partij betekent het weggeven van volledige controle over de bron die zich op de server bevindt.
Dat is waar de OAuth-authenticatiemethode te hulp schiet. Het introduceert een nieuwe rol in het authenticatieproces en het is de bron eigenaar. Nu zijn er drie rollen in het authenticatieproces:
De drie bovengenoemde rollen samen maken wat wordt genoemd als drie-legged OAuth-authenticatie. Het aantal poten definieert de rollen die betrokken zijn bij een authenticatieproces. Wanneer de broneigenaar ook de client is, wordt de flow bekend als two-legged-verificatie.
Volgens Webopedia:
OAuth is een open autorisatienorm die wordt gebruikt om beveiligde clienttoepassingstoegang tot serverbronnen te bieden. Het OAuth-autorisatiekader maakt het voor een externe toepassing mogelijk om gelimiteerde toegang tot een HTTP-service te verkrijgen, namens een broneigenaar of door de externe toepassing toegang te verlenen voor eigen rekening.
Met OAuth kunnen servereigenaren toegang tot de serverbronnen autoriseren zonder legitimatiegegevens te delen. Dit betekent dat de gebruiker toegang tot privébronnen van de ene server naar een andere serverbron kan verlenen zonder hun identiteit te delen.
Vandaar dat in de OAuth-authenticatiestroom de gebruiker geen inloggegevens hoeft bloot te leggen, maar de cliënt kan autoriseren om namens hem op te treden en te beslissen tot welke bronnen de client toegang heeft. Met andere woorden, hoewel de gebruiker geen inloggegevens verstrekt, kan hij ook beslissen over de reikwijdte van de toegang die de klant wordt verleend.
Hierdoor kunnen niet alleen websites, maar ook desktop- en mobiele applicaties beperkte toegang krijgen tot een bron op een server.
In termen van WordPress informeert OAuth de bronaanbieder (de WordPress-installatie) dat de broneigenaar (de WordPress-gebruiker) toestemming heeft verleend voor toegang tot een externe toepassing om toegang tot hun bronnen te krijgen. Deze bronnen kunnen van alles zijn zoals berichten, pagina's, taxonomie en media, etc. Deze toestemming kan voor beperkte of volledige toegang zijn, zoals we verderop in deze tutorial zullen zien.
De OAuth-authenticatie-API voor WordPress is gebouwd op basis van de OAuth 1.0a-specificaties, daarom zullen we kijken hoe OAuth 1.0a werkt.
OAuth werkt met tokenreferenties die worden uitgegeven door de bronprovider (de server), op verzoek van de broneigenaar nadat deze zichzelf heeft geverifieerd met behulp van de inloggegevens. Deze tokens (gekoppeld aan de eigenaar van de bron) worden vervolgens door de client gebruikt (een externe toepassing of service) om toegang te krijgen tot beschermde bronnen..
Deze tokenreferenties hebben een beperkte levensduur en kunnen door de server worden ingetrokken op verzoek van de broneigenaar.
De OAuth-stroom gaat als volgt:
Accentsconagua
oauth_consumer_key: geleverd door de serveroauth_timestampoauth_nonceoauth_signatureoauth_signature_methodoath_callbackoauth_version (Optioneel)oauth_tokenoauth_token_secretoauth_callback_confirmedoauth_token verkregen in de vorige stap naar de URI voor de endorsie van de Resource Owner Authorization.oauth_callback URI is in de eerste stap verstrekt, de server leidt de client om naar die URI en voegt het volgende als zoekreeks toe: oauth_token: verkregen in de tweede stapoauth_verifier: wordt gebruikt om ervoor te zorgen dat de eigenaar van de bron die toegang heeft verleend, dezelfde is die aan de client is geretourneerdoauth_callback URI werd niet verstrekt in de eerste stap, daarna geeft de server de waarde van de oauth_verifier zodat de eigenaar van de bron de client handmatig kan informeren.oauth_verfier, de client vraagt de server om tokenreferenties door een verzoek te verzenden naar de Token Request-eindpunt URI. Deze aanvraag bevat het volgende: oauth_token: verkregen in de tweede stapoauth_verfier: verkregen in de vorige stapoauth_consumer_key: verstrekt door de bronaanbieder (de server), voordat de handdruk wordt gestartoauth_signatureoauth_signature_methodoauth_nonceoauth_versionoauth_tokenoauth_token_secretDe bovenstaande informatie kan worden vervoerd door een queryreeks die is toegevoegd om URI's aan te vragen of door deze op te nemen in de machtiging header, hoewel de laatste wordt aanbevolen vanwege een betere beveiliging.
Dit is een langdurig proces en er moet rekening mee worden gehouden bij het ontwikkelen van onze eigen klanten voor interactie met de API. Het doel van de client is om al dit jargon te beheren en de gebruiker te helpen bij het authenticatieproces. Aangezien we een pakket van het WP REST API-team zullen gebruiken, zullen de bovenstaande gegevens worden weggevaagd en kunnen we tokensreferenties verkrijgen in een minimumaantal stappen.
In de bovenstaande discussie kwamen we drie eindpunt URI's tegen, namelijk:
Deze URI's worden door de server op verschillende manieren geleverd. Een van deze manieren is door ze bloot te stellen aan de serverreactie bij het controleren op de API. De OAuth-authenticatie-API voor WordPress REST API gebruikt dezelfde methode, zoals we in de volgende sectie zullen zien.
Nadat we hebben gekeken naar hoe OAuth werkt, is onze volgende stap het installeren en inschakelen van de OAuth-verificatie-API voor WordPress.
Met de OAuth-verificatie-API voor WordPress kan de server geverifieerde aanvragen accepteren met de OAuth-implementatie. Het is gebouwd op basis van OAuth 1.0a-specificaties en breidt deze uit met een extra parameter-wp_scope-worden verzonden naar de Tijdelijk legitimatie-verzoek eindpunt. De wp_scope parameter definieert de reikwijdte van de toegang die wordt verleend aan de client. Je kunt er meer over vinden in de officiële documentatie op GitHub.
De plug-in is beschikbaar op Github van het WP REST API-team en ondersteunt alleen versie 4.4 of later van WordPress.
Laten we de plug-in klonen door te navigeren naar de / Wp-content / plugins / directory:
$ git clone https://github.com/WP-API/OAuth1.git
Nadat de download is voltooid, activeer je de plug-in met behulp van WP CLI:
$ wp plugin activeert OAuth1
U kunt het ook activeren door in uw browser naar uw WordPress-gedeelte voor beheerdersinvoegtoepassingen te gaan als u WP CLI niet wilt gebruiken.
Dit is alles wat nodig is om de server in staat te stellen om OAuth als een autorisatiemethode te accepteren. Het volgende dat we moeten doen, is een verzoek naar de server sturen om te controleren of de OAuth API klaar is om gebruikt te worden.
Voordat we de OAuth-handshake starten, moeten we eerst controleren of de API is ingeschakeld op de server. Dit wordt gedaan door het verzenden van een eenvoudige KRIJGEN verzoek aan de/ Wp-json / eindpunt en analyse van het antwoord van de server.
Start uw HTTP-client op en verzend een verzoek naar de / Wp-json / eindpunt als volgt:
KRIJG http: // your-dev-server / wp-json /
Hiermee wordt een JSON-reactie als volgt geretourneerd:
Onze focus hier is de OAuth1 waarde in de authenticatie eigendoms-waarde. Dit object heeft de volgende eigenschappen gedefinieerd:
verzoek: het eindpunt van het tijdelijke legitimatie-verzoektoestemming geven: het eindpunt van de eigenaar van de resourcetoegang: het eindpunt van het tokenverzoekversie: de versie van OAuth die wordt gebruiktDe eerste drie zijn absolute URL's die we tegenkwamen toen we in een vorige sectie over het OAuth-mechanisme leerden.
De OAuth1 object gedefinieerd in de authenticatie eigenschapswaarde geeft aan dat de OAuth-API succesvol is ingeschakeld voor onze WordPress-site en we deze kunnen gaan gebruiken.
Als de OAuth-API niet is ingeschakeld voor een site, zou de serverreactie leeg zijn machtiging eigenschapswaarde als volgt:
Nu we de OAuth1.0a-plug-in hebben geïnstalleerd, laten we zien hoe we consumenten kunnen maken en beheren voor onze applicaties.
Nadat de plug-in OAuth1.0 met succes is geïnstalleerd, kunnen we consumenten voor onze applicaties maken en beheren door naar de WordPress-beheerder en vervolgens naar de Gebruikers> Toepassingen pagina.
Op dit Geregistreerde toepassingen pagina kunnen we een nieuwe applicatie registreren door op de knop Nieuw toevoegen te klikken en vervolgens de volgende drie velden in te vullen op de resulterende pagina:
Eenmaal gemaakt door op de te klikken Bewaar consument knop, de Client Key en Client Secret parameters verschijnen aan de onderkant van de pagina voor deze specifieke consument.
Deze Client Key en Client Secret parameters werken als oauth_consumer_key en oauth_consumer_secret parameters respectievelijk.
nieuwe Client Secret kan worden gemaakt door op de te klikken Regenereer geheim knop onderaan de pagina.
De OAuth-plug-in legt ook de functionaliteit bloot voor het maken van een consument in de console via de WP CLI-plug-in. Een nieuwe consument kan dus ook worden gemaakt met het volgende commando in de terminal:
wp oauth1 add --name =--description =
Deze nieuw gecreëerde consument verschijnt dan op de Geregistreerde toepassingen pagina waar u het kunt bewerken.
Na registratie van onze applicatie zijn we nu klaar om het OAuth-autorisatieproces in de volgende secties te starten.
Houd er rekening mee dat de plug-in OAuth1.0a op het moment van schrijven van deze zelfstudie het Client CLI-pakket niet meer ondersteunt. Het Client CLI-pakket kan in de nabije toekomst worden bijgewerkt met de nieuwste versie van de OAuth-plug-in, maar kijk voor nu naar het volgende gedeelte over het genereren van OAuth-referenties met behulp van een HTTP-client.
Het Client-CLI-pakket van het WP REST API-team maakt externe interactie mogelijk met een WordPress-site met behulp van WP-CLI en WP REST API. De bron is te vinden op GitHub.
Om dit pakket te gebruiken, moet u het volgende geïnstalleerd en geactiveerd hebben op de server waarop uw WordPress-installatie zich bevindt:
Op het apparaat (of de client) waarvan u verzoeken wilt genereren, moet het volgende worden geïnstalleerd:
U kunt de instructies vinden om de bovenstaande pakketten op hun respectieve sites te installeren.
Laten we met dat gezegd, de repository op de client klonen door de volgende opdracht uit te voeren:
$ git clone https://github.com/WP-API/client-cli
Navigeer nu naar de gekloonde directory en installeer pakketafhankelijkheden met Composer:
$ cd client-cli $ composer install
Als alles goed gaat, zou de commandolijn iets moeten tonen dat lijkt op het volgende:
Nu we het pakket hebben geïnstalleerd, zijn we klaar om tokenreferenties te genereren en op afstand te communiceren met WordPress REST API met OAuth.
Om het OAuth-autorisatieproces te starten, verkrijgen we eerst het volgende van de server:
oauth_consumer_keyoauth_consumer_secretDit kan worden gegenereerd door de terminal naar uw WordPress installatiedirectory op de server te leiden en de volgende WP CLI-opdracht uit te voeren:
$ wp oauth1 toevoegen
Dit genereert een uitvoer zoals de volgende:
De Sleutel en Geheim hier verkregen zijn de oauth_consumer_key en oauth_consumer_secret respectievelijk.
Nu moeten we de client koppelen aan onze WordPress-site. Ga op de client naar de client-cli map die u in de vorige sectie hebt gekloond en voer de volgende opdracht uit:
$ wp --require = client.php api oauth1 connect http: // your-dev-server / --key =--secret =
Vervang de URL en ook de sleutel en het geheim dat u in de vorige stap in de bovenstaande opdracht hebt verkregen. De uitvoer moet er als volgt uitzien:
$ wp --require = client.php api oauth1 connect http: // localserver / wordpress-api / --key = kXZMTt3O5hBZ --secret = ueDNeCfgNuyNyxkiU3qHGgWZWmGsg5lZwmMyhyjANsyYgz3Q Openen in uw browser: http: // localserver / wordpress-api / oauth1 / autoriseren ? oauth_token = wFxrd8OzcIL6lSRkLmmvViIe Voer de verificatiecode in:
Navigeer naar de URL die door de server is opgegeven en authenticeer uzelf door op de Toestemming geven knop:
U krijgt het verificatietoken te zien (of de oauth_verifier) op het volgende scherm:
Kopieer de verifier en plak deze in uw terminal. Je krijgt een Sleutel en een Geheim, die in feite jouw zijn oauth_token en oauth_token_secret respectievelijk:
U kunt deze tokenreferenties gebruiken in uw HTTP-client of elke andere toepassing die ondersteuning biedt voor het verzenden van geverifieerde aanvragen met de OAuth-API.
Omdat de OAuth 1.0a-serverplug-in de drieledige stroom volgt, omvat het genereren van OAuth-inloggegevens drie stappen:
Laten we beginnen met het implementeren van elk van de bovenstaande stappen met behulp van een HTTP-client, d.w.z. Postman.
Om tijdelijke inloggegevens te verkrijgen, sturen we een POST verzoek aan de / OAuth1 / aanvraag eindpunt. Dit tijdelijke legitimatie-verzoek eindpunt moet automatisch worden ontdekt omdat een server deze route kan vervangen door zijn eigen route. We hebben gekeken naar de functie voor automatische detectie tijdens het beoordelen van de beschikbaarheid van de OAuth-API in een vorige sectie.
De POST het verzoek moet de oauth_consumer_key en oauth_consumer_secret parameters die zijn verkregen bij het registreren van een consument voor de toepassing. Het verzoek kan ook de oauth_callback parameter en deze callback-URL moet overeenkomen met het schema, de host, de poort en het pad van de callback-URL die is opgegeven bij het registreren van de toepassing.
Los van de oauth_consumer_key en oauth_consumer_secret parameters, moet het verzoek ook de oauth_signature en oauth_signature_method parameters. Bij het gebruik van Postman, de oauth_signature wordt automatisch gegenereerd en we hoeven alleen maar de oauth_signature_method parameter. Momenteel zijn alleen de HMAC-SHA1 handtekeningmethode wordt ondersteund door de OAuth-serverplug-in.
De bovenstaande parameters kunnen op een van de volgende drie manieren worden doorgegeven:
machtiging hoofdKRIJGEN) queryparameters in de URLPOST) vraag lichaamsparameters aan. Het inhoudstype in dit geval zou moeten zijn application / x-www-form-urlencoded.Het is aan u om een van deze bovenstaande methoden te gebruiken om deze parameters naar de server te verzenden.
Laten we nu beginnen met het proces door Postman op te starten en een te sturen POST verzoek om het eindpunt eindpunt voor tijdelijke referenties. Maar kopieer daarvoor eerst de Gebruikers sleutel en Consumentengeheim parameters die door de nieuw geregistreerde toepassing worden verstrekt, omdat ze in deze stap nodig zullen zijn.
Stel postbode in om een bericht te verzenden POST verzoek om uw tijdelijke token referenties eindpunt. Dan in de machtiging tab, selecteer de OAuth 1.0 optie in de vervolgkeuzelijst. Vul de Gebruikers sleutel en Consumentengeheim velden met de waarden die door de consument zijn opgegeven. Zorg ervoor dat u controleert of de Handtekening Methode optie is ingesteld op HMAC-SHA1.
We hoeven geen andere waarden in te voeren dan deze. Klik op de Verzoek bijwerken knop en tenslotte stuur het verzoek door te klikken op de Sturen knop.
Als er geen fout is, retourneert de server a 200 - OK statuscode samen met het antwoordorgaan met een inhoudstype van application / x-www-form-urlencoded. Het hoofdgedeelte van dit verzoek ziet er ongeveer zo uit als de volgende reeks tekst:
oauth_token = tyNCKaL3WAJXib5SI6jCnr4P & oauth_token_secret = 1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF & oauth_callback_confirmed = true
Deze antwoordtekst bevat drie parameters voor de volgende stap van de driepotige stroom. Deze drie parameters zijn:
oauth_token: Een tijdelijk OAuth-token voor de autorisatiestap.oauth_token_secret: Een tijdelijk geheim om mee te gebruiken oauth_token.oauth_callback_confirmed: Deze parameters worden altijd geretourneerd, ongeacht of u de oauth_callback parameter in de eerste stap.Nu deze tijdelijke referenties gereed zijn, zijn we klaar voor de autorisatiestap voor gebruikers.
Voor de autorisatiestap voor gebruikers openen we het autorisatie-eindpunt van de broneigenaar in de browser en geven we het oauth_token en oauth_token_secret zoals verkregen in de vorige stap als queryparameters zoals de volgende:
http: // your-dev-server / OAuth1 / machtigen oauth_token =& Oauth_token_secret =
De browser zal u vragen om u aan te melden bij WordPress (als u nog niet bent aangemeld) en u vervolgens vragen om de toepassing te autoriseren:
Hier Geweldige applicatie is de naam van de geregistreerde toepassing.
Autoriseer de applicatie door op te klikken Toestemming geven knop en u krijgt een verificatietoken aangeboden op het volgende scherm:
Dit token fungeert als het oauth_verifier token in de volgende stap.
Nadat de gebruiker de client heeft geautoriseerd, wordt de toepassing weergegeven onder de Geautoriseerde applicaties sectie over de Gebruikers> Uw profiel pagina.
De volgende en de laatste stap in de driebenige stroom is token-uitwisseling. In deze stap worden de tijdelijke tokens die in de eerste stap zijn verkregen, ingewisseld voor een langlevend token dat door de klant kan worden gebruikt.
Om het token uitwisselingsproces te starten, schakelt u terug naar Postman en configureert u het om een te verzenden POST verzoek om het token-verzoek eindpunt.
Door de OAuth 1.0 optie opnieuw in de machtiging tab, vul de velden in voor Gebruikers sleutel en Consumentengeheim met waarden zoals verstrekt door de consument. Voor de blijk en Token Secret velden, gebruik de waarden van de oauth_token en oauth_token_secret parameters (tijdelijke inloggegevens) die in de eerste stap werden verkregen.
Aangezien we ook parameters in de URL als queryparameters kunnen doorgeven, voegt u de oauth_verifier parameter naar de URL als volgt:
http: // your-dev-server / OAuth1 / toegang oauth_verifier =
Als alle parameters aanwezig zijn, verzendt u het verzoek door op te klikken Sturen knop. Als alles goed gaat, zal de server een 200 - OK statuscode samen met de antwoordinstantie die bevat oauth_token en oauth_token_secret parameters.
oauth_token =& Oauth_token_secret =
Op dit punt worden de tijdelijke tokens die in de eerste stap zijn verkregen, verwijderd en kunnen deze niet langer worden gebruikt.
Deze nieuwe oauth_token en oauth_token_secret parameters zijn uw OAuth-referenties die u in uw client kunt gebruiken voor het genereren van geverifieerde aanvragen.
Nu we onze tokenreferenties hebben verkregen, kunnen we een testverzoek sturen naar de server met behulp van Postman om te zien of ze werken (natuurlijk doen ze dat!).
We sturen een DELETE verzoek aan de server om een bericht te verwijderen met een id van 50. Dit ID kan in uw geval anders zijn.
U moet het volgende hebben voordat u aan de slag gaat:
oauth_consumer_key: verkregen in de eerste stapoauth_consumer_secret: verkregen in de eerste stapoauth_token: verkregen in de laatste stapoauth_token_secret: verkregen in de laatste stapkiezen OAuth 1.0 uit de vervolgkeuzelijst onder de machtiging tab in Postman en vul de eerste vier velden in zoals hierboven vermeld. Hieronder ziet het hoe het eruit ziet:
Klik op de Verzoek bijwerken knop na het invullen van de velden. Controle van de Voeg params toe aan de header optie verzendt de parameters in de kop van het verzoek in plaats van ze in een querytekenreeks toe te voegen.
Stuur het verzoek en je krijgt een 200 - OK statuscode van de server, waaruit blijkt dat het bericht met succes is verwijderd.
In deze lange tutorial hebben we een overzicht gegeven van de OAuth-authenticatiemethode en hoe deze werkt om veilige gedelegeerde toegang te bieden tot applicaties en services van derden. We hebben ook de OAuth-authenticatie-API voor WordPress op de server ingesteld en deze gebruikt in combinatie met een HTTP-client om tokenreferenties te verkrijgen.
In het volgende deel van deze serie zullen we kijken naar het ophalen van content via de WP REST API. Blijf dus op de hoogte ...
