Share
I den föregående delen av serien skapade vi grundläggande HTTP-autentisering på servern genom att installera plugin som finns på GitHub av WP REST API-teamet. Den grundläggande autentiseringsmetoden tillåter oss att skicka autentiserade förfrågningar genom att skicka in inloggningsuppgifter i begäranhuvudet. Även om det är snabbt och praktiskt, finns det också en chans att dessa uppgifter kan falla i fela händer. Därför bör denna metod endast användas på säkra nät för utveckling och teständamål.
För att använda autentisering på produktionsservrar måste det finnas ett säkrare sätt att skicka autentiserade förfrågningar utan att riskera att exponera inloggningsuppgifterna. Tack vare OAuth-autentiseringsmetoden kan dessa förfrågningar skickas utan att användarnamnet och lösenordet exponeras på ett osäkert sätt.
I den nuvarande delen av serien lär vi oss att konfigurera och använda OAuth-autentiseringsmetoden som ska användas med pluginprogrammet WP REST API. För att vara specifik kommer vi att
Låt oss börja med att introducera oss till OAuth-autentiseringsmetoden.
Vad gör du när du behöver logga in på din WordPress-administratör? Du går helt enkelt till inloggningssidan och anger dina inloggningsuppgifter, eller hur? Det är enkelt! Men vad händer om du använder en tjänst från tredje part som kräver åtkomst till dina WordPress-resurser (inlägg, sidor, media eller något annat)? Skulle du helt enkelt överlämna dina inloggningsuppgifter till den tjänsten och veta att de kan hamna i fela händer när integriteten hos den tjänsten äventyras? Svaret skulle förmodligen vara "nej".
I den traditionella modellen för autentisering finns det två roller:
Om en klient vill få tillgång till skyddade resurser, skulle han eller hon bli autentiserad genom att tillhandahålla lämpliga referenser till servern och skulle få tillgång.
Problemet uppstår när en tredjeparts tjänst behöver tillgång till dessa skyddade resurser på servern. Denna tjänst kan inte vara (och skall inte vara) ges med uppgifter från användaren att få tillgång till resurser. Att tillhandahålla legitimationsuppgifter till en tredje part innebär att ge fullständig kontroll över resursen som finns på servern.
Det är där OAuth-autentiseringsmetoden kommer till räddning. Det introducerar en ny roll i autentiseringsprocessen, och det är det resursägare. Nu finns det tre roller i autentiseringsprocessen:
Ovanstående tre roller tillsammans gör det som kallas tre-leggs OAuth-autentisering. Antal ben definierar de roller som är inblandade i en autentiseringsprocess. När resursägaren är också klienten, blir flödet känt som tvåbeig autentisering.
Enligt Webopedia:
OAuth är en öppen godkännandestandard som används för att tillhandahålla säker klientapplikation till serverns resurser. OAuth-behörighetsramen gör det möjligt för en tredjepartsapplikation att få begränsad tillgång till en HTTP-tjänst, antingen på uppdrag av en resursägare eller genom att låta tredjepartsprogrammet få åtkomst för egen räkning.
OAuth gör det möjligt för serverns ägare att tillåta åtkomst till serverns resurser utan att dela med sig av uppgifter. Det innebär att användaren kan ge tillgång till privata resurser från en server till en annan serverresurs utan att dela med sig av sin identitet.
I OAuth-autentiseringsflödet behöver användaren inte avslöja uppgifter, utan kan tillåta klienten att agera på dess vägnar och bestämma vilka resurser kunden kan komma åt. Med andra ord kan användaren även bestämma omfattningen av den åtkomst som klienten beviljar, medan den inte ger inloggningsuppgifter.
Detta möjliggör inte bara webbplatser utan även skrivbords- och mobilapplikationer för att få begränsad tillgång till en resurs på en server.
När det gäller WordPress informerar OAuth resursleverantören (WordPress-installationen) att resursägaren (WordPress-användaren) har beviljat tillstånd att få tillgång till en tredje part för att få tillgång till sina resurser. Dessa resurser kan vara allt som inlägg, sidor, taxonomi och media etc. Denna tillåtelse kan vara för begränsad eller fullständig åtkomst, som vi kommer se senare i denna handledning.
OAuth-autentiserings API för WordPress bygger på OAuth 1.0a-specifikationer, så vi tar en titt på hur OAuth 1.0a fungerar.
OAuth fungerar med hjälp av token-referenser som utfärdas av resursleverantören (servern), på begäran av resursägaren efter att den har autentiserat sig genom att använda dess referenser. Dessa tokens som är associerade med resursägaren-används sedan av klienten (en tredjepartsapplikation eller tjänst) för att få tillgång till skyddade resurser.
Dessa token-uppgifter har en begränsad livstid och kan återkallas av servern på begäran av resursägaren.
OAuth-flödet går enligt följande:
Accentsconagua
oauth_consumer_key: tillhandahålls av servernoauth_timestampoauth_nonceoauth_signatureoauth_signature_methodoath_callbackoauth_version (valfri)oauth_tokenoauth_token_secretoauth_callback_confirmedoauth_token erhållet i föregående steg till URI för Resource Owner Authorization Endpoint.oauth_callback URI tillhandahölls i det första steget, servern omdirigerar klienten till den URI och lägger till följande som frågesträng: oauth_token: erhållen i det andra stegetoauth_verifier: används för att säkerställa att resursägaren som beviljat åtkomst är samma som returneras till kundenoauth_callback URI tillhandahölls inte i det första steget, så visar servern värdet på oauth_verifier så att resursägaren kunde informera kunden manuellt.oauth_verfier, Klienten begär servern för token-referenser genom att skicka en förfrågan till URI för Tokenförfrågan. Denna förfrågan innehåller följande: oauth_token: erhållen i det andra stegetoauth_verfier: erhållen i föregående stegoauth_consumer_key: tillhandahålls av resursleverantören (servern) innan du börjar oauth-handslagetoauth_signatureoauth_signature_methodoauth_nonceoauth_versionoauth_tokenoauth_token_secretOvanstående information kan antingen transporteras med en frågesträng som bifogas för att begära URI eller genom att inkludera den i Tillstånd header, även om den senare rekommenderas på grund av bättre säkerhet.
Detta är en lång process och bör beaktas när vi utvecklar våra egna kunder för att interagera med API: n. Syftet med klienten är att hantera allt detta jargong och underlätta användaren i autentiseringsprocessen. Eftersom vi kommer att använda ett paket som tillhandahålls av WP REST API-teamet kommer ovanstående detaljer att abstraheras bort och vi kommer att kunna få tokenuppgifter i ett minimalt antal steg.
I ovanstående diskussion kom vi över tre slutpunkts-URI: s, nämligen:
Dessa URI-enheter tillhandahålls av servern på olika sätt. Ett av dessa sätt är att exponera dem i serverns svar när du letar efter API: n. OAuth-autentiserings API för WordPress REST API använder samma metod som vi kommer att se i nästa avsnitt.
Efter att ha tittat på hur OAuth fungerar, är vårt nästa steg att installera och aktivera OAuth-autentiserings API för WordPress.
OAuth-autentiserings API för WordPress gör att servern kan acceptera autentiserade förfrågningar med hjälp av OAuth-implementering. Det bygger på OAuth 1.0a-specifikationer och utökar dem med ytterligare en parameter-wp_scope-att skickas till Tillfällig legitimationsbegäran slutpunkt. De wp_scope parametern definierar omfattningen av den åtkomst som ges till kunden. Du hittar mer om det i den officiella dokumentationen på GitHub.
Pluggen finns tillgänglig på Github från WP REST API-teamet och stöder endast version 4.4 eller senare av WordPress.
Låt oss klona pluginet genom att navigera till / Wp-content / plugins / katalogen:
$ git klon https://github.com/WP-API/OAuth1.git
När nedladdningen är klar aktiverar du plugin med WP CLI:
$ wp plugin aktiverar OAuth1
Alternativt kan du också aktivera den genom att navigera i din webbläsare till din WordPress admin plugins avsnitt om du inte vill använda WP CLI.
Detta är allt som behövs för att servern ska kunna acceptera OAuth som en auktoriseringsmetod. Nästa sak vi behöver göra är att skicka en begäran till servern för att kontrollera om OAuth API är redo att användas.
Innan vi initierar OAuth-handslaget bör vi först kontrollera om API: n är aktiverat på servern. Detta görs genom att skicka en enkel SKAFFA SIG begäran till/ Wp-json / slutpunkt och sedan analysera svaret som skickats av servern.
Slå på din HTTP-klient och skicka en förfrågan till / Wp-json / slutpunkt enligt följande:
Hämta http: // din-dev-server / wp-json /
Detta kommer att returnera ett JSON-svar enligt följande:
Vårt fokus här är OAuth1 värde i autentisering fastighetsvärde. Detta objekt har följande egenskaper definierade:
begäran: slutpunkten för den tillfälliga referensbegärangodkänna: Resource Owner Authorization Endpointtillgång: Tokenförfrågan slutpunktversion: den version av OAuth som användsDe första tre av dem är absoluta webbadresser som vi kom över när vi lärde oss om OAuth-mekanismen i ett tidigare avsnitt.
De OAuth1 objekt definierat i autentisering egendomsvärde visar att OAuth API har blivit aktiverat för vår WordPress-webbplats och vi kan börja använda det.
Om OAuth API inte är aktiverat för en webbplats, skulle serverns svar innehålla en tom tillstånd fastighetsvärde enligt följande:
Nu när vi har installerat OAuth1.0a-plugin, låt oss se hur vi kan skapa och hantera konsumenter för våra applikationer.
När OAuth1.0-plugin har installerats framgångsrikt kan vi skapa och hantera konsumenter för våra applikationer genom att gå till WordPress-administratören och sedan till Användare> Applikationer sida.
På den här Registrerade applikationer sida kan vi registrera en ny applikation genom att klicka på Lägg till ny knapp och sedan fylla i följande tre fält på den resulterande sidan:
En gång skapad genom att klicka på Spara konsumenten knapp, Klient nyckel och Kundhemlighet Parametrarna visas längst ner på sidan för den här konsumenten.
Dessa Klient nyckel och Kundhemlighet parametrar fungerar som oauth_consumer_key och oauth_consumer_secret parametrarna respektive.
Ny Kundhemlighet kan skapas genom att klicka på Regenerera Secret knappen längst ner på sidan.
OAuth-plugin-programmet visar också funktionaliteten för att skapa en konsument i konsolen genom WP CLI-plugin. Så en ny konsument kan också skapas av följande kommando i terminalen:
wp oauth1 lägg till --name =--description =
Den nybildade konsumenten kommer då att visas på Registrerade applikationer sida där du kan redigera den.
Efter att ha registrerat vår ansökan är vi nu redo att starta OAuth-auktoriseringsprocessen i följande avsnitt.
Observera att OAuth1.0a-plugin inte längre innehåller Client CLI-paketet när du skriver den här handledningen. Client CLI-paketet kan bli uppdaterat inom en snar framtid för att arbeta med den senaste versionen av OAuth-plugin, men för närvarande hänvisar du till nästa avsnitt om att generera OAuth-referenser med hjälp av en HTTP-klient.
Client-CLI-paketet från WP REST API-teamet möjliggör fjärransluten interaktion med en WordPress-webbplats med WP-CLI och WP REST API. Källan finns på GitHub.
För att använda detta paket måste du ha följande installerat och aktiverat på servern där din WordPress-installation finns:
På maskinen (eller klienten), från vilken du vill generera förfrågningar, måste följande installeras:
Du kan hitta instruktionerna för att installera ovanstående paket på respektive webbplatser.
Med det sagt, låt oss klona förvaret på klienten genom att köra följande kommando:
$ git klon https://github.com/WP-API/client-cli
Navigera nu i den klonade katalogen och installera paketberoende med hjälp av Kompositör:
$ cd client-cli $ composer install
Om allt går bra bör kommandoraden visa något som liknar följande:
Nu när vi har installerat paketet, är vi redo att generera token-referenser och interagera på distans till WordPress REST API med hjälp av OAuth.
För att starta OAuth-auktoriseringsprocessen får vi först följande från servern:
oauth_consumer_keyoauth_consumer_secretDetta kan genereras genom att styra terminalen till din WordPress installationskatalog på servern och köra följande WP CLI-kommando:
$ wp oauth1 lägg till
Detta kommer att generera en produktion som följande:
De Nyckel och Hemlighet erhållna här är oauth_consumer_key och oauth_consumer_secret respektive.
Nu måste vi länka klienten till vår WordPress-webbplats. På klienten, navigera till klient-cli katalog du klonade i föregående avsnitt och kör följande kommando:
$ wp --require = client.php api oauth1 anslut http: // your-dev-server / --key =--hemliga =
Byt ut webbadressen och även nyckeln och den hemlighet du fått i föregående steg i ovanstående kommando. Utgången ska vara som följande:
$ wp --require = client.php api oauth1 anslut http: // localserver / wordpress-api / --key = kXZMTt3O5hBZ --secret = ueDNeCfgNuyNyxkiU3qHGgWZWmGsg5lZwmMyhyjANsyYgz3Q Öppna i din webbläsare: http: // localserver / wordpress-api / oauth1 / authorize ? oauth_token = wFxrd8OzcIL6lSRkLmmvViIe Ange verifieringskoden:
Navigera till webbadressen som ges av servern och autentisera dig själv genom att klicka på Godkänna knapp:
Du kommer att presenteras med verifieringstoken (eller oauth_verifier) på nästa skärm:
Kopiera verifieraren och klistra in den i din terminal. Du kommer att få en Nyckel och a Hemlighet, som är i grunden din oauth_token och oauth_token_secret respektive:
Du kan använda dessa tokenuppgifter i din HTTP-klient eller någon annan applikation som stöder att skicka autentiserade förfrågningar med hjälp av OAuth API.
Eftersom OAuth 1.0a-serverns plugin följer trebensflödet, genererar OAuth-referenser tre steg:
Låt oss börja implementera var och en av ovanstående steg med hjälp av en HTTP-klient, dvs Postman.
För att få tillfälliga referenser skickar vi en POSTA begäran till / OAuth1 / begäran slutpunkt. Denna tillfälliga legitimationsförfrågan slutpunkten ska upptäckas automatiskt eftersom en server kan ersätta denna rutt med sin egen. Vi tittade på funktionen för automatisk upptäckt när vi bedömde tillgängligheten för OAuth API i en tidigare sektion.
De POSTA Förfrågan ska innehålla oauth_consumer_key och oauth_consumer_secret parametrar som förvärvats vid registrering av en konsument för ansökan. Förfrågan kan också innehålla oauth_callback parametern och den här återuppringningsadressen ska matcha schemat, värden, porten och sökvägen till återuppringningsadressen som gavs vid registrering av programmet.
Förutom oauth_consumer_key och oauth_consumer_secret parametrar, bör förfrågan också inkludera oauth_signature och oauth_signature_method parametrar. När du använder Postman, oauth_signature genereras automatiskt och vi behöver bara ange oauth_signature_method parameter. För närvarande bara den HMAC-SHA1 signaturmetoden stöds av OAuth-serverns plugin.
Ovannämnda parametrar kan skickas på något av följande tre sätt:
Tillstånd rubrikSKAFFA SIG) frågeparametrar i webbadressenPOSTA) begär kroppsparametrar. Innehållstypen i detta fall borde vara application / x-www-form-urlencoded.Det är upp till dig att använda någon av ovanstående metoder för att skicka dessa parametrar till servern.
Låt oss börja processen genom att skjuta upp Postman och skicka en POSTA Förfrågan till den tillfälliga legitimationen begär ändpunkt. Men före det, kopiera Konsumentnyckel och Konsumenthemlighet parametrar som tillhandahålls av den nyregistrerade applikationen som de kommer att behövas i detta steg.
Konfigurera Postman att skicka en POSTA Be om din slutpunkt för tillfällig tokenuppgifter. Sedan i Tillstånd fliken, välj OAuth 1.0 alternativet från rullgardinsmenyn. Fyll i Konsumentnyckel och Konsumenthemlighet fält med de värden som konsumenten tillhandahåller. Var noga med att kontrollera att Signaturmetod alternativet är inställt på HMAC-SHA1.
Vi behöver inte ange några andra värden än dessa. Klicka på Uppdateringsbegäran knappen och äntligen skicka förfrågan genom att klicka på Skicka knapp.
Om det inte finns något fel returnerar servern en 200 - OK statuskod tillsammans med svarskroppen med en innehållstyp av application / x-www-form-urlencoded. Den här förfrågan kroppen ser något ut som följande textsträng:
oauth_token = tyNCKaL3WAJXib5SI6jCnr4P & oauth_token_secret = 1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF & oauth_callback_confirmed = true
Denna svarkropp innehåller tre parametrar för nästa steg i trebensflödet. Dessa tre parametrar är:
oauth_token: En tillfällig OAuth-token för godkännandesteget.oauth_token_secret: En tillfällig hemlighet som ska användas tillsammans oauth_token.oauth_callback_confirmed: Dessa parametrar returneras alltid om du inte tillhandahåller oauth_callback parameter i det första steget.Med dessa tillfälliga legitimationsuppgifter är vi redo för användarautentiseringssteget.
För användarbehörighetsteget öppnar vi godkännandepunktet för resursens ägare i webbläsaren och skickar oauth_token och oauth_token_secret som erhållits i föregående steg som frågeparametrar som följande:
http: // your-dev-server / OAuth1 / godkänna oauth_token =& Oauth_token_secret =
Webbläsaren kommer att be dig att logga in på WordPress (om du inte redan är inloggad) och sedan be dig att godkänna programmet:
Här Awesome Application är namnet på den registrerade ansökan.
Godkänn ansökan genom att klicka på Godkänna knappen och du kommer att presenteras med en verifierings token på nästa skärm:
Denna token fungerar som oauth_verifier token i nästa steg.
När användaren har auktoriserat klienten visas programmet under Auktoriserade applikationer avsnitt på Användare> Din profil sida.
Nästa och sista steget i trebensflödet är token-utbyte. I detta steg utbyts de tillfälliga tokens som erhållits i det första steget för en långlivad token som kunde användas av kunden.
För att initiera token-utbytesprocessen, växla tillbaka till Postman och konfigurera den för att skicka en POSTA begära ändringspunkten för token-förfrågan.
Genom att använda OAuth 1.0 alternativet igen i Tillstånd fliken, fyll i fälten för Konsumentnyckel och Konsumenthemlighet med värden som tillhandahålls av konsumenten. För Tecken och Token Secret fält, använd värdena på oauth_token och oauth_token_secret parametrar (temporära referenser) som erhölls i det första steget.
Eftersom vi även kan skicka parametrar i webbadressen som sökparametrar, lägger du till oauth_verifier parameter till webbadressen enligt följande:
http: // your-dev-server / OAuth1 / tillgång oauth_verifier =
Med alla parametrar på plats, skicka förfrågan genom att klicka på Skicka knapp. Om allt går bra kommer servern att returnera en 200 - OK statuskoden tillsammans med svarkroppen som innehåller oauth_token och oauth_token_secret parametrar.
oauth_token =& Oauth_token_secret =
Vid denna tidpunkt kasseras de tillfälliga tokens som förvärvats i det första steget och kan inte längre användas.
Dessa nya oauth_token och oauth_token_secret parametrar är dina OAuth-referenser som du kan använda i din klient för att generera autentiserade förfrågningar.
Nu när vi har fått våra tokenuppgifter, kan vi skicka en testförfrågan till servern med Postman för att se om de fungerar (såklart kommer de!).
Vi skickar en RADERA Be till servern om att ta bort ett inlägg med ett id på 50. Detta ID kan vara annorlunda i ditt fall.
Du måste ha följande innan du börjar:
oauth_consumer_key: erhållen i det första stegetoauth_consumer_secret: erhållen i det första stegetoauth_token: erhållen i sista stegetoauth_token_secret: erhållen i sista stegetVälj OAuth 1.0 från rullgardinsmenyn under Tillstånd fliken i Postman och fyll i de fyra första fälten som nämnts ovan. Nedan är hur det ser ut:
Klicka på Uppdateringsbegäran knappen efter att ha fyllt i fälten. Kontrollerar Lägg till parametrar i rubriken alternativet skickar parametrarna i förfrågningsrubriken istället för att lägga till dem i en frågesträng.
Skicka förfrågan och du ska få en 200 - OK statuskod från servern, vilket visar att inlägget har tagits bort.
I den här långa handledningen tog vi en översikt över OAuth-autentiseringsmetoden och hur den fungerar för att ge säker delegerad tillgång till program och tjänster från tredje part. Vi inrättade också OAuth-autentiserings API för WordPress på servern och använde den tillsammans med en HTTP-klient för att få token-uppgifter.
I nästa del av denna serie tittar vi på att hämta innehåll via WP REST API. Så håll dig uppdaterad ...
