Share
I den forrige delen av serien konfigurerte vi grunnleggende HTTP-godkjenning på serveren ved å installere pluginet som er tilgjengelig på GitHub av WP REST API-teamet. Den grunnleggende godkjenningsmetoden lar oss sende godkjente forespørsler ved å sende innloggingsinformasjon i forespørselsoverskriften. Mens du er rask og hendig, er det også en sjanse for at disse legitimasjonene kan falle i feil hender. Derfor må denne metoden bare brukes på sikre nettverk for utvikling og testing.
For å bruke godkjenning på produksjonsservere må det være en sikrere måte å sende godkjente forespørsler uten å risikere å vise innloggingsinformasjonen. Takket være OAuth-autentiseringsmetoden kan disse forespørslene sendes uten å utsette brukernavnet og passordet på en usikker måte.
I den nåværende delen av serien vil vi lære å sette opp og bruke OAuth-autentiseringsmetoden som skal brukes med WP REST API-plugin. For å være spesifikk, vil vi:
La oss begynne med å introdusere oss selv i OAuth-autentiseringsmetoden.
Hva gjør du når du må logge på WordPress-admin? Du går ganske enkelt til påloggingssiden og skriver inn påloggingsinformasjonen, ikke sant? Det er enkelt! Men hva om du bruker en tredjepartstjeneste som krever tilgang til WordPress-ressursene dine (innlegg, sider, medier eller noe annet)? Vil du bare overlevere påloggingsinformasjonen din til den tjenesten, da du vet at de kan ende opp i feil hender når integriteten til den tjenesten blir kompromittert? Svaret vil trolig være "Nei".
I den tradisjonelle modellen for autentisering er det to roller:
Hvis en klient ønsker å få tilgang til beskyttede ressurser, vil han eller hun bli godkjent ved å gi passende legitimasjon til serveren og vil bli gitt tilgang.
Problemet oppstår når en tredjepartstjeneste trenger tilgang til disse beskyttede ressursene på serveren. Denne tjenesten kan ikke være (og bør ikke være) gitt legitimasjon av brukeren for å få tilgang til ressurser. Å gi legitimasjon til en tredjepart betyr å gi bort full kontroll over ressursen som ligger på serveren.
Det er her OAuth-autentiseringsmetoden kommer til redning. Det introduserer en ny rolle i autentiseringsprosessen, og det er den ressurs eier. Nå er det tre roller i autentiseringsprosessen:
Ovennevnte tre roller sammen gjør det som kalles trebent OAuth-autentisering. Antall ben definerer rollene som er involvert i en autentiseringsprosess. Når ressurs eieren er også klienten, blir strømmen kjent som to-legged autentisering.
Ifølge Webopedia:
OAuth er en åpen autorisasjonsstandard som brukes til å gi sikker klientprogramtilgang til serverressurser. OAuth-autorisasjonsrammen gjør det mulig for en tredjepartsprogram å få begrenset tilgang til en HTTP-tjeneste, enten på vegne av en ressurseier eller ved å tillate at tredjepartsprogrammet får tilgang på egne vegne.
OAuth gjør det mulig for servereiere å gi tilgang til serverressursene uten å dele legitimasjonsbeskrivelser. Dette betyr at brukeren kan gi tilgang til private ressurser fra en server til en annen serverressurs uten å dele identiteten sin.
Derfor, i OAuth-autentiseringsflyten, trenger brukeren ikke å fremlegge legitimasjonsbeskrivelser, men kan autorisere klienten til å handle på vegne av denne, og bestemme hvilke ressurser klienten har tilgang til. Med andre ord, selv om du ikke gir innloggingsinformasjon, kan brukeren også bestemme omfanget av tilgangen klienten får.
Dette gjør det mulig for ikke bare nettsteder, men også desktop og mobile applikasjoner å få begrenset tilgang til en ressurs på en server.
Når det gjelder WordPress, informerer OAuth ressursleverandøren (WordPress-installasjonen) at ressurseieren (WordPress-brukeren) har gitt tillatelse til tilgang til en tredjepartsprogram for tilgang til ressursene. Disse ressursene kan være alt som innlegg, sider, taksonomi og media etc. Denne tillatelsen kan være for begrenset eller fullstendig tilgang, som vi vil se senere i denne opplæringen.
OAuth-autentiseringsprogrammet for WordPress er bygd på toppen av OAuth 1.0a-spesifikasjonene, og derfor vil vi se på hvordan OAuth 1.0a fungerer.
OAuth fungerer ved å bruke token-legitimasjon som utstedes av ressursleverandøren (serveren), på forespørsel fra ressurseieren etter at den har autentisert seg ved å bruke legitimasjonene. Disse tokenene som er knyttet til ressurseieren, brukes da av klienten (en tredjepartsapplikasjon eller tjeneste) for å få tilgang til beskyttede ressurser.
Disse token-legitimasjonene har et begrenset levetid og kan tilbakekalles av serveren på forespørsel fra ressurseier.
OAuth-strømmen går som følger:
Accentsconagua
oauth_consumer_key: Leveres av serverenoauth_timestampoauth_nonceoauth_signatureoauth_signature_methodoath_callbackoauth_version (valgfri)oauth_tokenoauth_token_secretoauth_callback_confirmedoauth_token oppnådd i det forrige trinnet til URI for ressurseierautorisasjon.oauth_callback URI ble levert i første trinn, serveren omdirigerer klienten til den URI og legger til følgende som spørringsstreng: oauth_token: oppnådd i det andre trinnetoauth_verifier: brukes til å sikre at ressurseieren som har gitt tilgang, er den samme som returneres til klientenoauth_callback URI ble ikke gitt i første trinn, da viser serveren verdien av oauth_verifier slik at ressurseieren kunne informere klienten manuelt.oauth_verfier, Klienten ber om serveren for token-legitimasjon ved å sende en forespørsel til Endre-URI for Tokenforespørsel. Denne forespørselen inneholder følgende: oauth_token: oppnådd i det andre trinnetoauth_verfier: oppnådd i forrige trinnoauth_consumer_key: Leveres av ressursleverandøren (serveren), før du starter oauth-håndtrykketoauth_signatureoauth_signature_methodoauth_nonceoauth_versionoauth_tokenoauth_token_secretOvennevnte informasjon kan enten transporteres med en spørringsstreng som er vedlagt for å be om URI eller ved å inkludere den i Autorisasjon header, men sistnevnte anbefales på grunn av bedre sikkerhet.
Dette er en lang prosess og bør tas i betraktning når vi utvikler egne kunder for å samhandle med API. Formålet med klienten er å administrere alt dette jargong og forenkle brukeren i autentiseringsprosessen. Siden vi skal bruke en pakke levert av WP REST API-teamet, vil de ovennevnte detaljene bli abstrahert vekk, og vi vil kunne få token-legitimasjon i et minimum av trinn.
I den ovennevnte diskusjonen kom vi over tre endepunkt-URIer, nemlig:
Disse URIene leveres av serveren på forskjellige måter. En av disse måtene er å eksponere dem i serverresponsen når du kontrollerer API-en. OAuth-godkjennings API for WordPress REST API bruker samme metode, som vi vil se i neste avsnitt.
Etter å ha sett på hvordan OAuth fungerer, er vårt neste skritt å installere og aktivere OAuth-godkjennings API for WordPress.
OAuth-autentiseringsprogrammet for WordPress gjør det mulig for serveren å godta godkjente forespørsler ved hjelp av OAuth-implementering. Den er bygd på toppen av OAuth 1.0a-spesifikasjonene og utvider dem med en ekstra parameter-wp_scope-å bli sendt til Midlertidig legitimasjonsforespørsel endepunkt. De wp_scope parameter definerer omfanget av tilgangen som blir gitt til klienten. Du finner mer om det i den offisielle dokumentasjonen på GitHub.
Pluggen er tilgjengelig på Github fra WP REST API-teamet og støtter kun versjon 4.4 eller nyere av WordPress.
La oss klone pluginet ved å navigere til / Wp-content / plugins / katalogen:
$ git klon https://github.com/WP-API/OAuth1.git
Når nedlastingen er fullført, aktiver du pluginet ved hjelp av WP CLI:
$ wp plugin aktivere OAuth1
Alternativt kan du også aktivere den ved å navigere i nettleseren din til WordPress admin plugins-seksjonen hvis du ikke vil bruke WP CLI.
Dette er alt som trengs for at serveren skal kunne akseptere OAuth som en autorisasjonsmetode. Det neste vi må gjøre er å sende en forespørsel til serveren for å sjekke om OAuth API er klar til bruk.
Før vi starter OAuth-håndtrykket, bør vi først sjekke om API-en er aktivert på serveren. Dette gjøres ved å sende en enkel FÅ forespørsel til/ Wp-.json / sluttpunkt og deretter analysere svaret som sendes av serveren.
Slå opp HTTP-klienten din og send en forespørsel til / Wp-.json / sluttpunkt som følger:
FÅ http: // din-dev-server / wp-json /
Dette vil returnere en JSON-respons som følger:
Vårt fokus er her OAuth1 verdi i godkjenning Eiendomsverdi. Dette objektet har følgende egenskaper definert:
be om: Endrepunktet for midlertidig legitimasjonsforespørselautorisere: Resource Owner Authorization Endpointadgang: Tokenforespørsels endepunktetversjon: versjonen av OAuth brukesDe tre første er absolutt nettadresser som vi kom over da vi lærte om OAuth-mekanismen i en tidligere seksjon.
De OAuth1 objekt definert i godkjenning eiendomsverdi viser at OAuth API har blitt aktivert for vårt WordPress-nettsted, og vi kan begynne å bruke det.
Hvis OAuth API ikke er aktivert for et nettsted, vil serverresponsen inneholde en tom autorisasjon eiendomsverdi som følger:
Nå som vi har installert OAuth1.0a-pluginet, kan vi se hvordan vi kan opprette og administrere forbrukerne for våre applikasjoner.
Når OAuth1.0-pluginet er installert, kan vi opprette og administrere forbrukerne for våre applikasjoner ved å gå til WordPress-administrasjonen og deretter til Brukere> Programmer side.
På dette Registrerte applikasjoner side, kan vi registrere et nytt program ved å klikke på Legg til ny knapp og deretter fylle ut de følgende tre feltene på den resulterende siden:
En gang opprettet ved å klikke på Lagre forbrukeren knappen, den Klientnøkkel og Klientshemmelighet Parametrene vises nederst på siden for denne forbrukeren.
Disse Klientnøkkel og Klientshemmelighet parametere fungerer som oauth_consumer_key og oauth_consumer_secret parametere henholdsvis.
Ny Klientshemmelighet kan opprettes ved å klikke på Regenerere hemmelighet knappen nederst på siden.
OAuth-pluginet viser også funksjonaliteten for å opprette en forbruker i konsollen gjennom WP CLI-plugin. Så en ny forbruker kan også opprettes av følgende kommando i terminalen:
wp oauth1 legg til --name =--description =
Denne nyopprettede forbrukeren vil da vises på Registrerte applikasjoner side der du kan redigere den.
Etter å ha registrert søknaden vår, er vi nå klare til å starte autorisasjonsprosessen for OAuth i de følgende avsnittene.
Vær oppmerksom på at når du skriver denne veiledningen, støtter ikke OAuth1.0a-plugin-modulen Client CLI-pakken lenger. Client CLI-pakken kan bli oppdatert i nær fremtid for å jobbe med den nyeste versjonen av OAuth-pluginet, men for nå, vennligst se neste avsnitt om å generere OAuth-legitimasjon ved hjelp av en HTTP-klient.
Client-CLI-pakken av WP REST API-teamet muliggjør ekstern samhandling med et WordPress-nettsted ved hjelp av WP-CLI og WP REST API. Kilden finnes på GitHub.
For å bruke denne pakken må du ha følgende installert og aktivert på serveren der WordPress-installasjonen din er plassert:
På maskinen (eller klienten), hvorfra du ønsker å generere forespørsler, må følgende være installert:
Du finner instruksjonene for å installere de ovennevnte pakkene på deres respektive nettsteder.
Med det sagt, la oss klone oppbevaringen på klienten ved å kjøre følgende kommando:
$ git klon https://github.com/WP-API/client-cli
Naviger nå inn i den klonede katalogen og installer pakkeavhengigheter ved å bruke Komponist:
$ cd client-cli $ composer installere
Hvis alt går bra, burde kommandolinjen vise noe som ligner på følgende:
Nå som vi har installert pakken, er vi klare til å generere token-legitimasjon og samhandle eksternt til WordPress REST API ved hjelp av OAuth.
For å starte OAuth-autorisasjonsprosessen, oppnår vi først følgende fra serveren:
oauth_consumer_keyoauth_consumer_secretDette kan genereres ved å lede terminalen til WordPress-installasjonsmappen på serveren og kjøre følgende WP CLI-kommando:
$ wp oauth1 legg til
Dette vil generere en utgang som følgende:
De Nøkkel og Hemmelig hentet her er oauth_consumer_key og oauth_consumer_secret henholdsvis.
Nå må vi koble klienten til vår WordPress-side. På klienten navigerer du til klient-cli katalog du klonet i forrige seksjon og kjør følgende kommando:
$ wp --require = client.php api oauth1 koble http: // din-dev-server / --key =--hemmelige =
Erstatt nettadressen og også nøkkelen og hemmeligheten du oppnådde i forrige trinn i kommandoen ovenfor. Utgangen bør være som følger:
$ wp --require = client.php api oauth1 koble http: // localserver / wordpress-api / --key = kXZMTt3O5hBZ --secret = ueDNeCfgNuyNyxkiU3qHGgWZWmGsg5lZwmMyhyjANsyYgz3Q Åpne i nettleseren din: http: // localserver / wordpress-api / oauth1 / authorize ? oauth_token = wFxrd8OzcIL6lSRkLmmvViIe Angi bekreftelseskoden:
Naviger til nettadressen gitt av serveren og autentiser deg ved å klikke på Autorisere knapp:
Du vil bli presentert med verifikasjonstoken (eller oauth_verifier) på neste skjermbilde:
Kopier verifikatoren og lim den inn i terminalen din. Du vil bli gitt en Nøkkel og a Hemmelig, som er i utgangspunktet din oauth_token og oauth_token_secret henholdsvis:
Du kan bruke disse token-legitimasjonene i din HTTP-klient eller et annet program som støtter å sende godkjente forespørsler ved hjelp av OAuth API.
Siden OAuth 1.0a-tjenerpluggen følger trebensstrømmen, genererer OAuth-legitimasjon tre trinn:
La oss begynne å implementere hvert av trinnene ovenfor ved hjelp av en HTTP-klient, dvs. Postman.
For å få tak i midlertidig legitimasjon sender vi en POST forespørsel til / OAuth1 / forespørsel endepunkt. Dette midlertidige legitimasjonsforespørselsendepunktet skal oppdages automatisk ettersom en server kan erstatte denne ruten med sin egen. Vi så på funksjonen for automatisk oppdagelse mens du vurderte tilgjengeligheten av OAuth API i en tidligere seksjon.
De POST forespørsel bør inkludere oauth_consumer_key og oauth_consumer_secret parametere som er oppnådd når du registrerer en forbruker for søknaden. Forespørselen kan også inkludere oauth_callback parameteren og denne tilbakekallingsadressen bør samsvare med ordningen, verten, porten og banen til tilbakekallingsadressen som ble oppgitt når du registrerte søknaden.
Bortsett fra oauth_consumer_key og oauth_consumer_secret Parametere, forespørselen bør også inkludere oauth_signature og oauth_signature_method parametre. Når du bruker Postman, oauth_signature genereres automatisk, og vi trenger bare å spesifisere oauth_signature_method parameter. For tiden er det bare HMAC-SHA1 Signaturmetoden støttes av OAuth server plugin.
Ovennevnte parametere kan bestås på en av følgende tre måter:
Autorisasjon OverskriftFÅ) spørringsparametere i nettadressenPOST) Be om kroppsparametere. Innholdstypen i dette tilfellet skal være application / x-www-skjema-urlencoded.Det er opp til deg å bruke noen av disse metodene ovenfor for å sende disse parameterne til serveren.
La oss nå starte prosessen ved å skyte opp Postman og sende en POST Forespørsel til det midlertidige legitimasjonsforespørsler om sluttpunkt. Men før det, kopier du Forbrukernøkkel og Forbrukerhemmelig parametere som angitt av den nyregistrerte søknaden som de vil være nødvendige i dette trinnet.
Konfigurer Postmannen til å sende en POST Forespørsel til ditt midlertidige token-legitimasjonsendepunkt. Så i Autorisasjon fanen, velg OAuth 1.0 alternativ fra rullegardinmenyen. Fyll ut Forbrukernøkkel og Forbrukerhemmelig felt med verdiene som tilbys av forbrukeren. Pass på at du kontrollerer at Signaturmetode alternativet er satt til HMAC-SHA1.
Vi trenger ikke å skrive inn noen andre verdier enn disse. Klikk på Oppdateringsforespørsel knappen og endelig send forespørselen ved å klikke på Sende knapp.
Hvis det ikke er noen feil, returnerer serveren a 200 - OK statuskode sammen med svaret kroppen har en innholdstype av application / x-www-skjema-urlencoded. Denne forespørselsorganisasjonen ser noe ut som følgende tekststreng:
oauth_token = tyNCKaL3WAJXib5SI6jCnr4P & oauth_token_secret = 1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF & oauth_callback_confirmed = true
Denne respons kroppen inneholder tre parametre for neste trinn av tre-legged flyt. Disse tre parametrene er:
oauth_token: Et midlertidig OAuth-token for autorisasjonstrinnet.oauth_token_secret: En midlertidig hemmelighet som skal brukes sammen oauth_token.oauth_callback_confirmed: Disse parameterne returneres alltid om du ikke oppgir oauth_callback parameter i første trinn.Med disse midlertidige legitimasjonene klare, er vi klare for brukerautorisasjonstrinnet.
For brukerautorisasjonstrinnet åpner vi autorisasjonens endepunkt i nettleseren og sender passordet oauth_token og oauth_token_secret som oppnådd i forrige trinn som spørringsparametere som følgende:
http: // your-dev-server / OAuth1 / godkjenne oauth_token =& Oauth_token_secret =
Nettleseren vil be deg om å logge på WordPress (hvis du ikke allerede er innlogget), og deretter vil du be om å godkjenne programmet:
Her Fantastisk applikasjon er navnet på den registrerte søknaden.
Godkjen søknaden ved å klikke på Autorisere knappen og du vil bli presentert med et bekreftelsestoken på neste skjermbilde:
Dette token fungerer som oauth_verifier token i neste trinn.
Når brukeren har godkjent klienten, vises søknaden under Autoriserte applikasjoner delen på Brukere> Din profil side.
Det neste og det siste trinnet i trebensstrømmen er token-utveksling. I dette trinnet blir de midlertidige tokens som er oppnådd i første trinn utvekslet for et langvarig token som kan brukes av klienten.
For å starte tokenutvekslingsprosessen, bytt tilbake til Postman og konfigurer den for å sende en POST forespørsel til token-anmodningsendepunktet.
Ved å bruke OAuth 1.0 alternativet igjen i Autorisasjon fan, fyll ut feltene for Forbrukernøkkel og Forbrukerhemmelig med verdier som tilbys av forbrukeren. For pollett og Token Secret felt, bruk verdiene til oauth_token og oauth_token_secret parametere (midlertidig legitimasjon) som ble oppnådd i første trinn.
Siden vi også kan sende parametere i nettadressen som søkeparametere, legger du til oauth_verifier parameter til nettadressen som følger:
http: // your-dev-server / OAuth1 / tilgang oauth_verifier =
Med alle parametrene på plass, send forespørselen ved å klikke på Sende knapp. Hvis alt går bra, vil serveren returnere en 200 - OK statuskode sammen med responslegemet som inneholder oauth_token og oauth_token_secret parametere.
oauth_token =& Oauth_token_secret =
På dette tidspunktet blir de midlertidige tokens som er anskaffet i første trinn, kassert og kan ikke lenger brukes.
Disse nye oauth_token og oauth_token_secret Parametere er OAuth-legitimasjonene du kan bruke i klienten din for å generere godkjente forespørsler.
Nå som vi har fått våre token-legitimasjon, kan vi sende en testforespørsel til serveren ved hjelp av Postman for å se om de jobber (selvfølgelig vil de!).
Vi sender en SLETT Be om at serveren skal slette et innlegg med et id på 50. Dette ID-en kan være forskjellig i ditt tilfelle.
Du må ha følgende før du kommer i gang:
oauth_consumer_key: oppnådd i første trinnoauth_consumer_secret: oppnådd i første trinnoauth_token: oppnådd i siste trinnoauth_token_secret: oppnådd i siste trinnÅ velge OAuth 1.0 fra rullegardinmenyen under Autorisasjon tab i Postman, og fyll de fire første feltene som nevnt ovenfor. Nedenfor er hvordan det ser ut:
Klikk på Oppdateringsforespørsel knappen etter at du har fylt ut feltene. Kontrollerer Legg til params i header alternativet sender parametrene i overskriften til forespørselen i stedet for å legge dem i en spørringsstreng.
Send forespørselen, og du bør få en 200 - OK statuskode fra serveren, og viser at innlegget har blitt slettet.
I denne lange opplæringen tok vi en oversikt over OAuth-autentiseringsmetoden og hvordan den fungerer for å gi sikker delegert tilgang til tredjeparts applikasjoner og tjenester. Vi oppretter også OAuth-autentiserings API for WordPress på serveren og brukte den sammen med en HTTP-klient for å få token-legitimasjon.
I neste del av denne serien ser vi på å hente innhold gjennom WP REST API. Så hold deg oppdatert ...
