Share
În partea anterioară a seriei, am creat autentificare HTTP de bază pe server instalând pluginul disponibil pe GitHub de către echipa WP REST API. Metoda de autentificare de bază ne permite să trimitem cereri autentice prin trimiterea acreditărilor de autentificare în antetul solicitării. În timp ce sunteți rapid și la îndemână, există și o șansă ca aceste acreditări să cadă în mâinile greșite. Prin urmare, această metodă ar trebui utilizată numai în rețele securizate numai pentru scopuri de dezvoltare și testare.
Pentru a utiliza autentificarea pe serverele de producție, trebuie să existe o modalitate mai sigură de a trimite cereri autentificate fără a risca expunerea acreditărilor de autentificare. Datorită metodei de autentificare OAuth, aceste solicitări pot fi trimise fără a expune numele de utilizator și parola în mod nesigur.
În partea curentă a seriei, vom învăța să configuram și să folosim metoda de autentificare OAuth care va fi utilizată împreună cu pluginul WP REST API. Pentru a fi specific, vom:
Să începem prin introducerea în metoda de autentificare OAuth.
Ce faceți atunci când trebuie să vă conectați la administratorul dvs. WordPress? Accesați pur și simplu pagina de conectare și introduceți datele de conectare, nu? E simplu! Dar dacă utilizați un serviciu terț care necesită acces la resursele dvs. WordPress (postări, pagini, mass-media sau orice altceva)? V-ați transfera pur și simplu acreditările dvs. de conectare la acel serviciu, știind că acestea ar putea ajunge în mâini greșite ori de câte ori integritatea serviciului respectiv este compromisă? Răspunsul ar fi probabil "nu".
În modelul tradițional de autentificare, există două roluri:
Dacă un client dorește să acceseze resurse protejate, el sau ea s-ar autentifica prin furnizarea de acreditări adecvate serverului și ar fi acordat acces.
Problema apare atunci când un serviciu terță parte are nevoie de acces la aceste resurse protejate de pe server. Acest serviciu nu poate fi (și ar trebui să să nu fie) date de acreditare de către utilizator pentru a accesa resurse. Furnizarea de acreditări unei terțe părți înseamnă eliberarea controlului complet asupra resursei aflate pe server.
Aici a ajuns la salvarea metodologia de autentificare OAuth. Acesta introduce un nou rol în procesul de autentificare, și este proprietarul resurselor. Acum există trei roluri în procesul de autentificare:
Cele trei roluri de mai sus fac împreună ceea ce se numește autentificare OAuth cu trei picioare. Numărul de picioare definește rolurile implicate într-un proces de autentificare. Atunci când proprietarul resursei este și clientul, fluxul devine cunoscut ca autentificare cu două picioare.
Potrivit Webopedia:
OAuth este un standard de autorizare deschis utilizat pentru a asigura accesul sigur al aplicațiilor client la resursele serverului. Cadrul de autorizare OAuth permite unei aplicații terțe să obțină acces limitat la un serviciu HTTP, fie în numele unui proprietar al unei resurse, fie permițând aplicației terțe să obțină acces în nume propriu.
OAuth permite proprietarilor de servere să autorizeze accesul la resursele serverului fără a împărtăși acreditările. Aceasta înseamnă că utilizatorul poate acorda acces la resurse private de la un server la o altă resursă de server fără a-și împărtăși identitatea.
Prin urmare, în fluxul de autentificare OAuth, utilizatorul nu are nevoie să expună acreditări, ci poate autoriza clientul să acționeze în numele său, hotărând ce resurse poate avea accesul clientului. Cu alte cuvinte, în timp ce nu oferă acreditări de autentificare, utilizatorul poate decide și domeniul de aplicare al accesului la care este acordat clientul.
Aceasta permite nu numai site-uri web, ci și aplicații desktop și mobile să obțină acces limitat la o resursă de pe un server.
În ceea ce privește WordPress, OAuth informează furnizorul de resurse (instalarea WordPress) că proprietarul resursei (utilizatorul WordPress) a acordat permisiunea de a accesa o aplicație terță parte pentru a-și accesa resursele. Aceste resurse pot fi orice fel de postări, pagini, taxonomie și media etc. Această permisiune poate fi accesul limitat sau complet, așa cum vom vedea mai târziu în acest tutorial.
API-ul de autentificare OAuth pentru WordPress este construit pe baza specificațiilor OAuth 1.0a, prin urmare vom analiza cum funcționează OAuth 1.0a.
OAuth funcționează utilizând acreditările de jetoane care sunt emise de furnizorul de resurse (serverul), la cererea proprietarului resursei, după ce sa autentificat prin utilizarea acreditărilor sale. Aceste jetoane asociate cu proprietarul resursei sunt apoi utilizate de client (o aplicație sau serviciu terță parte) pentru a avea acces la resurse protejate.
Aceste acreditări ale tokenului au o durată de viață limitată și pot fi revocate de către server la cererea proprietarului resursei.
Fluxul OAuth merge după cum urmează:
Accentsconagua
oauth_consumer_key: furnizate de serveroauth_timestampoauth_nonceoauth_signatureoauth_signature_methodoath_callbackoauth_version (Opțional)oauth_tokenoauth_token_secretoauth_callback_confirmedoauth_token obținută în etapa anterioară la URI pentru punctul de final al autorizației pentru proprietarul resurselor.oauth_callback URI a fost furnizat în primul pas, serverul redirecționează clientul către acel URI și adaugă următoarele ca șir de interogări: oauth_token: obținută în a doua etapăoauth_verifier: utilizat pentru a se asigura că proprietarul resursei care a acordat accesul este același returnat clientuluioauth_callback URI nu a fost furnizat în primul pas, apoi serverul afișează valoarea lui oauth_verifier astfel încât proprietarul resursei să poată informa clientul manual.oauth_verfier, clientul solicită serverul pentru acreditările de jetoane prin trimiterea unei cereri către URI-ul punctului de solicitare al Token Request. Această solicitare conține următoarele: oauth_token: obținută în a doua etapăoauth_verfier: obținută în etapa anterioarăoauth_consumer_key: furnizat de furnizorul de resurse (serverul), înainte de a începe oauth handshakeoauth_signatureoauth_signature_methodoauth_nonceoauth_versionoauth_tokenoauth_token_secretInformațiile de mai sus pot fi transmise fie printr-un șir de interogare atașat la solicitarea URI, fie prin includerea acestuia în Autorizare header, deși acesta din urmă este recomandat datorită unei mai bune securități.
Acesta este un proces de lungă durată și trebuie luat în considerare atunci când ne dezvoltăm propriii clienți pentru a interacționa cu API-ul. Scopul clientului este de a gestiona toate aceste jargon și de a facilita utilizatorul în procesul de autentificare. Deoarece vom folosi un pachet oferit de echipa WP REST API, detaliile de mai sus vor fi abstracte și vom putea obține acreditări de jetoane într-un număr minim de pași.
În discuția de mai sus, am descoperit trei URI-uri de final, și anume:
Aceste URI-uri sunt furnizate de server în diverse moduri. Una dintre aceste modalități este expunerea acestora la răspunsul la server atunci când verificați API-ul. API-ul de autentificare OAuth pentru API-ul WordPress REST utilizează aceeași metodă, după cum vom vedea în următoarea secțiune.
După ce am analizat cum funcționează OAuth, următorul pas este să instalați și să activați API-ul de autentificare OAuth pentru WordPress.
API-ul de autentificare OAuth pentru WordPress permite serverului să accepte cereri autentificate utilizând implementarea OAuth. Este construit pe baza specificațiilor OAuth 1.0a și le extinde printr-un parametru suplimentar-wp_scope-pentru a fi trimise la Cerere de acreditare temporară punct final. wp_scope parametru definește domeniul de aplicare al accesului acordat clientului. Puteți afla mai multe despre aceasta în documentația oficială despre GitHub.
Pluginul este disponibil pe Github de la echipa WP REST API și suportă doar versiunea 4.4 sau o versiune ulterioară a WordPress.
Să clonăm pluginul navigând la / Wp-content / plugins / director:
$ git Clone https://github.com/WP-API/OAuth1.git
După terminarea descărcării, activați pluginul utilizând WP CLI:
$ wp plugin activează OAuth1
Alternativ, o puteți activa, de asemenea, navigând browserul dvs. în secțiunea de pluginuri de administrare WordPress dacă nu doriți să utilizați WP CLI.
Acesta este tot ceea ce este necesar pentru a permite serverului să accepte OAuth ca metodă de autorizare. Următorul lucru pe care trebuie să-l facem este să trimiteți o solicitare serverului pentru a verifica dacă API-ul OAuth este gata de utilizare.
Înainte de a iniția o strângere de mână OAuth, trebuie mai întâi să verificăm dacă API-ul este activat pe server. Acest lucru se face prin trimiterea unui simplu OBȚINE cererea către/ Wp-json / și apoi analizând răspunsul trimis de server.
Porniți clientul dvs. HTTP și trimiteți o solicitare către / Wp-json / după cum urmează:
GET http: // dvs.-dev-server / wp-json /
Acest lucru va returna un răspuns JSON după cum urmează:
Accentul nostru este aici oauth1 valoare în autentificare Valoarea proprietății. Acest obiect are următoarele proprietăți definite:
cerere: obiectivul de solicitare a acreditărilor temporareautoriza: obiectivul de autorizare pentru proprietarul resurseloracces: obiectivul solicitării Tokenversiune: versiunea OAuth utilizatăPrimele trei dintre acestea sunt adrese URL absolute pe care le-am întâlnit când învățam despre mecanismul OAuth dintr-o secțiune anterioară.
oauth1 obiect definit în autentificare valoarea proprietății arată că API-ul OAuth a fost activat cu succes pentru site-ul nostru WordPress și putem începe să îl folosim.
Dacă API-ul OAuth nu este activat pentru un site, răspunsul serverului va conține un mesaj gol autorizare valoarea proprietății după cum urmează:
Acum, că am instalat pluginul OAuth1.0a, să vedem cum putem crea și gestiona consumatorii pentru aplicațiile noastre.
Odată ce pluginul OAuth1.0 a fost instalat cu succes, putem crea și gestiona consumatorii pentru aplicațiile noastre, accesând administratorul WordPress și apoi Utilizatori> Aplicații pagină.
Pe aceasta Cererile înregistrate , puteți să înregistrați o nouă aplicație dând clic pe butonul Adăugați o nouă și apoi completând următoarele trei câmpuri pe pagina care rezultă:
Odată creat făcând clic pe Salvați consumatorul butonul, Cheia clientului și Secretul clientului parametrii vor apărea în partea de jos a paginii pentru acest anumit consumator.
Aceste Cheia clientului și Secretul clientului parametrii acționează ca oauth_consumer_key și oauth_consumer_secret parametrii respectivi.
Nou Secretul clientului poate fi creat făcând clic pe Regenerați secretul în partea de jos a paginii.
Pluginul OAuth expune de asemenea funcționalitatea pentru crearea unui consumator în consola prin pluginul WP CLI. Astfel, un nou consumator poate fi, de asemenea, creat de următoarea comandă în terminal:
wp oauth1 adăugați --name =--descriere =
Acest consumator nou creat va apărea apoi pe Cererile înregistrate pagina în care o puteți edita.
După înregistrarea cererii noastre, suntem gata să începem procesul de autorizare OAuth în următoarele secțiuni.
Rețineți că, la scrierea acestui tutorial, pluginul OAuth1.0a nu mai acceptă pachetul Client CLI. Pachetul Client CLI se poate actualiza în viitorul apropiat pentru a lucra cu cea mai recentă versiune a pluginului OAuth, dar pentru moment, vă rugăm să consultați secțiunea următoare despre generarea acreditărilor OAuth utilizând un client HTTP.
Pachetul client-CLI de către echipa WP REST API permite interacțiunea de la distanță cu un site WordPress care utilizează API-urile WP-CLI și WP REST. Sursa poate fi găsită pe GitHub.
Pentru a utiliza acest pachet, va trebui să aveți instalat și activat următoarele pe serverul în care este localizată instalarea WordPress:
Pe mașina (sau clientul), de unde doriți să generați solicitări, trebuie instalate următoarele:
Puteți găsi instrucțiunile pentru instalarea pachetelor de mai sus pe site-urile respective.
Cu aceasta a spus, să clonăm depozitul pe client executând următoarea comandă:
$ git clone https://github.com/WP-API/client-cli
Acum, navigați în directorul clonat și instalați dependențele de pachete utilizând Composer:
Instalarea $ cd client-cli $ compozitor
Dacă totul merge bine, linia de comandă ar trebui să arate ceva similar cu următorul:
Acum că am instalat pachetul, suntem gata să generăm acreditări token și să interacționăm de la distanță la WordPress REST API folosind OAuth.
Pentru a începe procesul de autorizare OAuth, primim mai întâi următoarele informații de la server:
oauth_consumer_keyoauth_consumer_secretAcest lucru poate fi generat prin direcționarea terminalului în directorul de instalare WordPress de pe server și executarea următoarei comenzi WP CLI:
$ wp oauth1 adăugați
Aceasta va genera o ieșire cum ar fi:
Cheie și Secret obținute aici sunt oauth_consumer_key și oauth_consumer_secret respectiv.
Acum trebuie să conectăm clientul la site-ul nostru WordPress. Pe client, navigați la client-cli directorul pe care l-ați clonat în secțiunea anterioară și executați următoarea comandă:
$ wp --require = client.php api oauth1 conectați http: // your-dev-server / -key =--= secrete
Înlocuiți URL-ul și, de asemenea, cheia și secretul obținut în pasul anterior din comanda de mai sus. Rezultatul ar trebui să fie după cum urmează:
$ wp --require = client.php api oauth1 conectați http: // localserver / wordpress-api / --key = kXZMTt3O5hBZ --secret = ueDNeCfgNuyNyxkiU3qHGgWZWmGsg5lZwmMyhyjANsyYgz3Q Deschideți în browser-ul dvs.: http: // localserver / wordpress-api / oauth1 / authorize ? oauth_token = wFxrd8OzcIL6lSRkLmmvViIe Introduceți codul de verificare:
Navigați la adresa URL dată de server și autentificați-vă făcând clic pe Autoriza buton:
Vi se va afișa simbolul de verificare (sau oauth_verifier) pe următoarea fereastră:
Copiați verificatorul și introduceți-l în terminal. Vi se va da a Cheie și a Secret, care sunt în esență dvs. oauth_token și oauth_token_secret respectiv:
Puteți utiliza aceste acreditări de jetoane în clientul dvs. HTTP sau în orice altă aplicație care acceptă trimiterea de cereri autentificate utilizând API-ul OAuth.
Deoarece pluginul de server OAuth 1.0a urmează fluxul cu trei picioare, generarea de acreditări OAuth implică trei etape:
Să începem implementarea fiecăruia dintre pașii de mai sus folosind un client HTTP, adică Postman.
Pentru a obține acreditări temporare, trimitem a POST cererea către / Oauth1 / cerere punct final. Acest punct final al cererii de acreditare temporară ar trebui să fie descoperit automat, deoarece un server ar putea înlocui acest traseu cu propriul său. Am analizat caracteristica de descoperire automată în timp ce evaluăm disponibilitatea API-ului OAuth într-o secțiune anterioară.
POST cererea ar trebui să includă oauth_consumer_key și oauth_consumer_secret parametrii obținuți la înregistrarea unui consumator pentru cerere. Cererea ar putea include și oauth_callback parametru și această adresă URL de apel invers ar trebui să se potrivească cu schema, gazda, portul și calea adresei URL de apel invers care a fost furnizată la înregistrarea aplicației.
În afară de oauth_consumer_key și oauth_consumer_secret parametrii, cererea ar trebui să includă și oauth_signature și oauth_signature_method parametrii. Când folosiți Postman, oauth_signature este generat automat și trebuie doar să specificăm oauth_signature_method parametru. În prezent, numai HMAC-SHA1 metoda de semnare este acceptată de pluginul serverului OAuth.
Parametrii de mai sus pot fi trecuți în oricare dintre următoarele trei moduri:
Autorizare antetOBȚINE) în URLPOST) solicita parametrii corpului. În acest caz, tipul de conținut ar trebui să fie application / x-www-form-urlencoded.Depinde de dvs. să utilizați oricare din aceste metode de mai sus pentru a trimite acești parametri pe server.
Hai să începem procesul prin aruncarea lui Postman și trimiterea lui a POST solicitați obiectivul final al cererii de acreditare temporară. Dar înainte de aceasta, copiați Cheia de consum și Secretul consumatorilor parametrii prevăzuți de cererea nou înregistrată, deoarece acestea vor fi necesare în acest pas.
Configurați poștașul pentru a trimite a POST solicitați punct final pentru acreditările temporare ale tokenului. Apoi în Autorizare , selectați OAuth 1.0 opțiune din meniul derulant. Completați Cheia de consum și Secretul consumatorilor cu valori furnizate de consumator. Asigurați-vă că verificați dacă Metoda de semnare opțiunea este setată la HMAC-SHA1.
Nu este nevoie să introduceți alte valori decât acestea. Apasă pe Cerere de actualizare și trimiteți în final solicitarea făcând clic pe Trimite buton.
Dacă nu există nicio eroare, serverul va returna a - OK codul de stare împreună cu organismul de răspuns având un tip de conținut de application / x-www-form-urlencoded. Acest organism de solicitare arată ceva de genul următorului șir de text:
oauth_token = tyNCKaL3WAJXib5SI6jCnr4P & oauth_token_secret = 1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF & oauth_callback_confirmed = true
Acest organism de răspuns conține trei parametri pentru următoarea etapă a fluxului cu trei picioare. Acești trei parametri sunt:
oauth_token: Un jeton temporar OAuth pentru etapa de autorizare.oauth_token_secret: Un secret temporar pentru a fi folosit de-a lungul oauth_token.oauth_callback_confirmed: Acești parametri se întorc întotdeauna dacă furnizați sau nu oauth_callback parametru în primul pas.Cu aceste acreditări temporare gata, suntem pregătiți pentru etapa de autorizare a utilizatorului.
Pentru pasul de autorizare pentru utilizator, deschideți punctul de destinație al autorizației pentru proprietar al resursei în browser și treceți oauth_token și oauth_token_secret obținută în etapa anterioară ca parametri de interogare, cum ar fi:
http: // dvs.-dev-server / oauth1 / autoriza oauth_token =& Oauth_token_secret =
Browserul vă va cere să vă conectați la WordPress (dacă nu sunteți deja conectat) și apoi vă va cere să autorizați aplicația:
Aici Aplicație minunată este numele aplicației înregistrate.
Autorizați aplicația dând clic pe Autoriza și veți primi un jeton de verificare pe următoarea fereastră:
Acest simbol acționează ca oauth_verifier în pasul următor.
Odată ce utilizatorul a autorizat clientul, aplicația va apărea sub Cereri autorizate secțiune pe Utilizatori> Profilul tău pagină.
Următorul și ultimul pas în fluxul cu trei picioare este schimbul de jetoane. În acest pas, jetoanele temporare obținute în prima etapă sunt schimbate pentru un token cu durată lungă de viață care ar putea fi utilizat de către client.
Pentru a iniția procesul de schimbare a tokenului, reveniți la Postman și configurați-l pentru a trimite un mesaj POST solicitați la punctul final al solicitării token.
Prin utilizarea funcției OAuth 1.0 opțiune din nou în Autorizare filă, completați câmpurile pentru Cheia de consum și Secretul consumatorilor cu valori furnizate de consumator. Pentru Jeton și Secretul secretului câmpuri, utilizați valorile oauth_token și oauth_token_secret parametrii (acreditările temporare) care au fost obținute în prima etapă.
Deoarece putem transmite parametrii în URL ca parametri de interogare, adăugați oauth_verifier parametru la adresa URL, după cum urmează:
http: // dvs.-dev-server / oauth1 / Acces oauth_verifier =
Cu toți parametrii în loc, trimiteți cererea dând clic pe Trimite buton. Dacă totul merge bine, serverul va returna a - OK cod de stare împreună cu corpul de răspuns care conține oauth_token și oauth_token_secret parametrii.
oauth_token =& Oauth_token_secret =
În acest moment, jetoanele temporare dobândite în prima etapă sunt aruncate și nu mai pot fi folosite.
Aceste noi oauth_token și oauth_token_secret parametrii sunt acreditările dvs. OAuth pe care le puteți utiliza în clientul dvs. pentru generarea de cereri autentificate.
Acum, că am obținut acreditările noastre de jeton, putem trimite o solicitare de testare la server folosind Postman pentru a vedea dacă funcționează (desigur că vor!).
Vom trimite un mesaj ȘTERGE cereți serverului să ștergă o postare cu un id de 50. Acest id poate fi diferit în cazul tău.
Va trebui să aveți următoarele înainte de a începe:
oauth_consumer_key: obținută în prima etapăoauth_consumer_secret: obținută în prima etapăoauth_token: obținută în etapa finalăoauth_token_secret: obținută în etapa finalăSelectați OAuth 1.0 din drop-down sub Autorizare în Postman și completați primele patru câmpuri, după cum este menționat mai sus. Mai jos este ceea ce pare:
Apasă pe Cerere de actualizare după completarea câmpurilor. Verificați Adăugați paramurile în antet opțiunea trimite parametrii în antetul solicitării în loc să le atașeze într-un șir de interogări.
Trimiteți cererea și ar trebui să obțineți o - OK cod de stare de la server, care arată că postul a fost șters cu succes.
În acest tutorial de lungă durată am făcut o prezentare generală a metodei de autentificare OAuth și a modului în care funcționează pentru a oferi accesul delegat sigur la aplicații și servicii terță parte. De asemenea, am creat API-ul de autentificare OAuth pentru WordPress pe server și l-am folosit împreună cu un client HTTP pentru a obține acreditări token.
În următoarea parte a acestei serii, vom căuta la preluarea conținutului prin WP REST API. Deci stați liniștit ...
