In het inleidende gedeelte van deze serie hebben we een snelle bijscholing gehad over de REST-architectuur en hoe deze ons kan helpen betere applicaties te maken. Vervolgens hebben we de geschiedenis van REST-API's in WordPress onderzocht en hebben we ons voorgesteld aan de nieuwste toevoeging: de WP REST API-plug-in. We hebben een eenvoudige werkomgeving opgezet om met de plug-in te testen, waaronder plug-in installatie en een HTTP-client voor het verzenden van aanvragen of het bekijken van de serverreactie..
In het huidige deel van de serie zullen we een basisverificatieprotocol instellen op de server om geverifieerde aanvragen te verzenden om verschillende taken uit te voeren via de REST API.
Om specifiek te zijn, in dit deel zullen we:
bekijk verschillende beschikbare authenticatiemethoden bij het gebruik van de REST API-plug-in
basisverificatie instellen op de server
stuur een geverifieerd verzoek met behulp van Postman
stuur een geverifieerd verzoek met JavaScript-framework
stuur een geverifieerd verzoek met behulp van de opdrachtregel
stuur een geverifieerd verzoek met behulp van de WP HTTP API
Maar laten we eerst eens kijken naar de authenticatie zelf.
Wat is verificatie?
In de meest elementaire definitie is verificatie het proces om de identiteit van een persoon te bepalen.
Volgens Webopedia:
Het proces van het identificeren van een persoon, meestal op basis van een gebruikersnaam en wachtwoord. In beveiligingssystemen onderscheidt authenticatie zich van autorisatie, wat het proces is om individuen toegang te geven tot systeemobjecten op basis van hun identiteit. Authenticatie zorgt er alleen voor dat het individu is wie hij of zij beweert te zijn, maar zegt niets over de toegangsrechten van het individu.
Wanneer het over WP REST API gaat, kan een gebruiker met voldoende rechten verschillende CRUD-taken uitvoeren, zoals het maken van een bericht, het ophalen van alle gebruikers van de site of het intrekken van de rechten van een gebruiker. Maar voor al deze acties moet men zijn / haar identiteit aan de server bewijzen, en dat is waar de authenticatie een rol speelt.
Zonder de juiste authenticatie zou het voor een persoon met ondeugende ambities heel gemakkelijk zijn om met de site te rommelen, zodat authenticatie een noodzakelijke beveiligingslaag biedt om de rechten van een gebruiker en de acties die kunnen worden uitgevoerd te beperken.
Authenticatie met de WP REST API
De WP REST API biedt drie opties voor authenticatie, elk bestemd voor een specifiek doel. Deze opties zijn:
basisverificatie
OAuth-authenticatie
cookie-authenticatie
Op dit moment is de native manier om te authenticeren met WordPress authenticatie door cookies. Dit is hoe WordPress de identiteit van een gebruiker bepaalt en welke acties hij kan uitvoeren. Om de andere twee authenticatiemethoden hierboven vermeld met de WP REST API te gebruiken, moeten we hun respectieve plug-ins installeren die geleverd worden door het WP REST API-team dat beschikbaar is op GitHub. Hopelijk worden deze twee methoden ook opgenomen in de WordPress-kern met de REST API-plug-in zelf.
Basisverificatie is het meest basale type HTTP-verificatie, waarbij aanmeldingsreferenties worden verzonden samen met de koppen van het verzoek.
Hoe Basic Authentication werkt
Bij basisverificatie vraagt de client een URL aan die verificatie vereist. De server vraagt de client (of user-agent) zichzelf te verifiëren door een 401-Niet geautoriseerd code. De client stuurt in ruil hetzelfde verzoek terug, maar met inloggegevens als een base64-gecodeerde reeks in het formaat gebruikersnaam wachtwoord. Deze tekenreeks wordt verzonden in de machtiging koptekstveld als volgt:
Dus als de gebruikersnaam is tutsplus en het wachtwoord is 123456, het volgende headerveld zou met het verzoek worden verzonden:
Autorisatie: Basic dHV0c3BsdXM6MTIzNDU2
Omdat de base64-gecodeerde reeks eenvoudig kan worden gedecodeerd, is deze methode zeer onveilig om op een open netwerk te worden gebruikt. Daarom moet deze methode alleen worden gebruikt voor foutopsporing en ontwikkelingsdoeleinden wanneer de verbinding tussen de server en de client vertrouwd is.
De plug-in installeren
Zoals hierboven vermeld, is de plug-in beschikbaar op GitHub van het WP REST API-team. Dus alles wat we moeten doen is het klonen in onze plugins map en activeer het.
Ga naar je / Wp-content / plugins / directory en klonen de plug-in waarvoor u mogelijk nodig hebt sudo rechten om het commando uit te voeren. Hiertoe het volgende doen:
De terminal zal om uw wachtwoord vragen. Voer je wachtwoord in en laat de repository in een map worden gekloond.
Nadat u de plug-in hebt gekloond, activeert u deze door naar uw WP-beheerder te gaan. De standaard HTTP-authenticatiemethode kan nu worden gebruikt met de REST API-plug-in.
Authentieke verzoeken verzenden met Postman
De meeste HTTP-clients ondersteunen het verzenden van een verzoek met behulp van de standaard authenticatiemethode, en dat geldt ook voor Postman voor Chrome. Om een geverifieerd verzoek te verzenden, gaat u naar machtiging tab onder de adresbalk:
Selecteer nu Basisverificatie uit het vervolgkeuzemenu. U wordt gevraagd om uw gebruikersnaam en wachtwoord in te voeren. Klik na het invoeren van uw inloggegevens op Update aanvraag knop.
Nadat u de verificatieoptie hebt bijgewerkt, ziet u een wijziging in de headers tabblad en bevat nu een koptekstveld met de gecodeerde gebruikersnaam en wachtwoordreeks:
Dat is alles over hoe we basisverificatie instellen met Postman. Nu kunt u een testverzoek sturen, zoals het verwijderen van een bericht, waarvoor authenticatie vereist is:
Waar dev-server is het pad naar uw ontwikkelserver.
Als alles goed gaat, zal de server een 200 OK statuscode, waarmee wordt aangegeven dat de post met een ID van 52 is verwijderd:
Maak je geen zorgen over het verzoek dat we hier hebben gedaan - we zullen het in meer detail doornemen in de toekomstige delen van de serie.
Het verzenden van geverifieerde aanvragen vanaf de opdrachtregel
We kunnen de opdrachtregel gebruiken om geverifieerde aanvragen met behulp van deze methode te verzenden. Stel je de volgende situatie voor Krul equivalent van het bovenstaande verzoek:
De --verzoek optie specificeert de te gebruiken verzoekmethode, wat in ons geval is DELETE. Je kan ook gebruiken -X als een alternatief voor de --verzoek keuze.
De -ik optie haalt alleen de HTTP-headers op die door de server zijn verzonden. De alternatief voor -ik is de --hoofd keuze.
Authentieke verzoeken verzenden met JavaScript
Als u een client-side JavaScript-framework gebruikt, zoals jQuery, om op afstand te communiceren met een WordPress-site met WP API ingeschakeld, kunt u de autorisatieheaders verzenden in een AJAX-verzoek. Stel je de volgende situatie voor DELETE verzoek verzonden via de jQuery.ajax () methode:
Waar Base64 is een object dat wordt gebruikt voor het coderen en decoderen van een base64-tekenreeks. Het is als volgt gedefinieerd, voorafgaand aan het bovenstaande jQuery.ajax () methode aanroep:
var Base64 = _ keyStr: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 + / =", coderen: functie (e) var; var n, r, i, s, o, u, a; var f = 0; e = Base64._utf8_encode (e); while (f> 2 o = (n & 3)<<4|r>> 4, u = (r & 15)<<2|i>> 6, a = i&63;if (isNaN (r)) u = a = 64 else if (isNaN (i)) a = 64 t = t + this._keyStr.charAt (s) + this._keyStr.charAt (o) + this ._keyStr.charAt (u) + this._keyStr.charAt (a) return t, decode: functie (e) var; var n, r, i; var s, o, u, a; var f = 0 ; e = e.replace (/ [^ A-Za-z0-9 \ + \ / \ =] / g ""), terwijl (f> 4, r = (o & 15)<<4|u>> 2, i = (u & 3)<<6|a;t=t+String.fromCharCode(n);if(u!=64)t=t+String.fromCharCode(r)if(a!=64)t=t+String.fromCharCode(i)t=Base64._utf8_decode(t);return t,_utf8_encode:function(e)e=e.replace(/\r\n/g,"\n");var;for(var n=0;n127 && r<2048)t+=String.fromCharCode(r>> 6 | 192); t + = String.fromCharCode (r & 63 | 128) else t + = String.fromCharCode (r >> 12 | 224); t + = String.fromCharCode (r >> 6 & 63 | 128); t + = String .vanCharCode (r & 63 | 128) return t, _ utf8_decode: function (e) var; var n = 0; var r = c1 = c2 = 0; while (n191 && r<224)c2=e.charCodeAt(n+1);t+=String.fromCharCode((r&31)<<6|c2&63);n+=2elsec2=e.charCodeAt(n+1);c3=e.charCodeAt(n+2);t+=String.fromCharCode((r&15)<<12|(c2&63)<<6|c3&63);n+=3return t;
Ik vond het op StackOverflow, en het is een cross-browser manier voor het coderen en decoderen van een base64 string in JavaScript.
In het bovenstaande verzoek hebben we de machtiging koptekst met behulp van de setRequestHeader () methode van de XHR object doorgegeven als een argument voor de beforeSend () methode.
In aanvulling op het bovenstaande verzoek, de Access-Control-Sta-Headers headers moeten de machtiging veld op de server. Dit kan worden ingeschakeld door de volgende coderegel toe te voegen aan uw WordPress .htaccess-bestand:
Het bovenstaande verzoek, wanneer voltooid, zal het antwoord in de console van uw browser weergeven zoals getoond in de onderstaande figuur:
De 200 status reactiecode geretourneerd door de server laat zien dat de post met een id van 52 is succesvol verwijderd.
Authentieke aanvragen verzenden met behulp van de WP HTTP API
Als u op afstand interactie hebt met een andere WordPress-site vanuit uw WordPress-installatie, is de WP HTTP API de geschiktste manier om HTTP-verzoeken te verzenden.
Overweeg de volgende code die een verzendt DELETE verzoek om een andere WordPress-installatie met WP REST API en standaard authenticatie ingeschakeld:
Hier hebben we de wp_remote_request () functie die twee argumenten accepteert:
$ url: de URL van het verzoek
$ args: een reeks aanvullende argumenten die moeten worden doorgegeven
De $ methode gedefinieerd in de $ args array is DELETE, en het moet altijd in hoofdletters worden geschreven. De $ headers array neemt sleutelwaardeparen van alle headervelden die moeten worden doorgegeven met het verzoek. We zijn geslaagd voor de machtiging sleutel met een base64-gecodeerde gebruikersnaam en wachtwoordreeks als waarde.
Het antwoord zou worden opgeslagen in de $ wp_delete_post_response variabele, die we kunnen gebruiken met de wp_remote_retrieve_response_code () en wp_remote_retrieve_response_message () functies. Deze twee functies zijn helperfuncties in de WP HTTP API en ze extraheren respectievelijk de statuscode en het statusbericht van het antwoord.
Als het bericht met succes is verwijderd door het bovenstaande verzoek, wordt de volgende tekst weergegeven:
200 OK
Dat is alles over de basisverificatiemethode die wordt ondersteund door WP REST API. We zullen dezelfde authenticatiemethode gebruiken in onze toekomstige delen voor het ophalen, creëren of wijzigen van gegevens vanwege de eenvoud, tenzij anders vermeld.
Conclusie
In het huidige deel van de serie hebben we de standaard HTTP-verificatiemethode die wordt ondersteund door de WP REST API, nader bekeken. Het mag echter niet worden gebruikt in live productieomgevingen vanwege het feit dat de base64-gecodeerde reeks eenvoudig kan worden gedecodeerd en uw inloggegevens in de verkeerde handen kunnen vallen.
Nadat we de HTTP-basisverificatiemethode met succes hebben ingesteld en getest, zijn we klaar om een stap verder te gaan en een meer geavanceerde manier van authenticatie in te stellen: de OAuth 1.0a-methode. Dat doen we in het volgende deel van de serie, dus houd het in de gaten!
Share
Accentsconagua
