API RIP WP impostazione e utilizzo dell'autenticazione OAuth 1.0a

Nella parte precedente della serie, abbiamo impostato l'autenticazione HTTP di base sul server installando il plug-in disponibile su GitHub dal team dell'API REST di WP. Il metodo di autenticazione di base ci consente di inviare richieste autenticate inviando credenziali di accesso nell'intestazione della richiesta. Pur essendo veloce e maneggevole, c'è anche la possibilità che queste credenziali possano finire nelle mani sbagliate. Quindi questo metodo dovrebbe essere usato solo su reti sicure solo per scopi di sviluppo e test.

Per utilizzare l'autenticazione sui server di produzione, è necessario disporre di un modo più sicuro di inviare richieste autenticate senza rischiare di esporre le credenziali di accesso. Grazie al metodo di autenticazione OAuth, tali richieste possono essere inviate senza esporre il nome utente e la password in un modo non sicuro.

Nella parte attuale della serie, impareremo a configurare e utilizzare il metodo di autenticazione OAuth da utilizzare con il plug-in API REST WP. Per essere precisi, noi:

  • fai una panoramica del metodo di autenticazione OAuth e di come funziona
  • installa il plugin del server OAuth
  • generare un token di accesso OAuth da utilizzare nella nostra app

Iniziamo introducendo noi stessi al metodo di autenticazione OAuth.

Presentazione dell'autenticazione OAuth

Che cosa fai quando devi accedere al tuo amministratore di WordPress? Vai semplicemente alla pagina di accesso e inserisci le tue credenziali di accesso, giusto? È semplice! Ma cosa succede se stai utilizzando un servizio di terze parti che richiede l'accesso alle risorse di WordPress (post, pagine, contenuti multimediali o altro)? Vuoi semplicemente consegnare le credenziali di accesso a quel servizio, sapendo che potrebbero finire in mani sbagliate ogni volta che l'integrità di tale servizio è compromessa? La risposta sarebbe probabilmente "No".

Nel modello tradizionale di autenticazione, ci sono due ruoli:

  1. Il cliente: può essere un utente, un'applicazione o un servizio
  2. Il fornitore di risorse: il server in cui si trovano le risorse protette

Se un cliente desidera accedere a risorse protette, viene autenticato fornendo credenziali appropriate al server e gli viene concesso l'accesso.

Il problema sorge quando un servizio di terze parti ha bisogno di accedere a queste risorse protette sul server. Questo servizio non può essere (e dovrebbero non essere) dato le credenziali dell'utente per accedere alle risorse. Fornire credenziali a terzi significa cedere il controllo completo sulla risorsa che si trova sul server. 

È qui che la metodologia di autenticazione OAuth viene in soccorso. Introduce un nuovo ruolo nel processo di autenticazione ed è il proprietario di risorse. Ora ci sono tre ruoli nel processo di autenticazione:

  1. Il cliente: non l'utente stesso ma un'applicazione o un servizio di terzi che agisce per conto dell'utente e accede a risorse protette
  2. Il server: il server in cui si trovano le risorse protette
  3. Il proprietario della risorsa: l'utente stesso

I tre ruoli di cui sopra fanno ciò che viene definito come autenticazione OAuth a tre vie. Il numero di gambe definisce i ruoli coinvolti in un processo di autenticazione. Quando il proprietario della risorsa è anche il client, il flusso diventa noto come autenticazione a due gambe.

Secondo la Webopedia:

OAuth è uno standard di autorizzazione aperto utilizzato per fornire accesso sicuro alle applicazioni client alle risorse del server. Il framework di autorizzazione OAuth consente a un'applicazione di terze parti di ottenere un accesso limitato a un servizio HTTP, per conto di un proprietario di risorse o consentendo all'applicazione di terze parti di ottenere l'accesso per proprio conto.
OAuth consente ai proprietari dei server di autorizzare l'accesso alle risorse del server senza condividere le credenziali. Ciò significa che l'utente può concedere l'accesso a risorse private da un server a un'altra risorsa server senza condividere la propria identità.

Quindi nel flusso di autenticazione OAuth, l'utente non ha bisogno di esporre le credenziali ma può autorizzare il client ad agire per suo conto, decidendo quali risorse possono accedere al client. In altre parole, pur non fornendo le credenziali di accesso, l'utente può anche decidere l'ambito dell'accesso al client.

Ciò consente non solo ai siti Web ma anche alle applicazioni desktop e mobili di ottenere un accesso limitato a una risorsa su un server.

In termini di WordPress, OAuth informa il fornitore di risorse (l'installazione di WordPress) che il proprietario della risorsa (l'utente di WordPress) ha concesso l'autorizzazione ad accedere a un'applicazione di terze parti per accedere alle proprie risorse. Queste risorse possono essere qualcosa come post, pagine, tassonomia e media, ecc. Questa autorizzazione può essere per accesso limitato o completo, come vedremo più avanti in questo tutorial.

Come funziona il flusso di autenticazione OAuth

L'API di autenticazione OAuth per WordPress è basata sulle specifiche di OAuth 1.0a, quindi daremo un'occhiata a come funziona OAuth 1.0a.

OAuth funziona utilizzando le credenziali dei token che vengono rilasciate dal provider di risorse (il server), su richiesta del proprietario della risorsa dopo che si è autenticata utilizzando le sue credenziali. Questi token, associati al proprietario della risorsa, vengono quindi utilizzati dal client (un'applicazione o servizio di terze parti) per accedere alle risorse protette.

Queste credenziali dei token hanno una durata limitata e possono essere revocate dal server su richiesta del proprietario della risorsa.

Il flusso di OAuth è il seguente:

  1. Il client invia una richiesta firmata al server per ottenere un Token di richiesta, conosciuto anche come Credenziali temporanee. Questa richiesta viene inviata al Credenziali temporanee URI dell'endpoint e contiene quanto segue:
    • oauth_consumer_key: fornito dal server
    • oauth_timestamp
    • oauth_nonce
    • oauth_signature
    • oauth_signature_method
    • oath_callback
    • oauth_version (opzionale)
  2. Il server verifica la richiesta e, se è valida, concede un token di richiesta che contiene:
    • oauth_token
    • oauth_token_secret
    • oauth_callback_confirmed
  3. Il client invia quindi il proprietario della risorsa (l'utente) al server per autorizzare la richiesta. Questo viene fatto costruendo un URI di richiesta aggiungendo oauth_token ottenuto nel passaggio precedente all'URI dell'endpoint Autorizzazione proprietario risorsa.
  4. Il proprietario della risorsa (l'utente) autorizza sul server fornendo le credenziali.
  5. Se la oauth_callback L'URI è stato fornito nel primo passaggio, il server reindirizza il client a quell'URI e aggiunge il seguente come stringa di query:
    • oauth_token: ottenuto nel secondo passaggio
    • oauth_verifier: utilizzato per garantire che il proprietario della risorsa che ha concesso l'accesso sia lo stesso restituito al client
  6. Se la oauth_callback L'URI non è stato fornito nel primo passaggio, quindi il server visualizza il valore di oauth_verifier in modo che il proprietario della risorsa potesse informare il cliente manualmente.
  7. Dopo aver ricevuto oauth_verfier, il client richiede al server credenziali per token inviando una richiesta all'URI dell'endpoint di richiesta token. Questa richiesta contiene quanto segue:
    • oauth_token: ottenuto nel secondo passaggio
    • oauth_verfier: ottenuto nel passaggio precedente
    • oauth_consumer_key: fornito dal fornitore di risorse (il server), prima di avviare l'handshake oauth
    • oauth_signature
    • oauth_signature_method
    • oauth_nonce
    • oauth_version
  8. Il server verifica la richiesta e concede il seguente, noto come credenziali token:
    • oauth_token
    • oauth_token_secret
  9. Il client utilizza quindi credenziali token per accedere alle risorse protette sul server.

Le informazioni di cui sopra possono essere trasportate da una stringa di query aggiunta per richiedere URI o includendola nel file Autorizzazione intestazione, sebbene quest'ultima sia raccomandata a causa di una maggiore sicurezza.

Questo è un processo lungo e dovrebbe essere preso in considerazione nello sviluppo dei nostri clienti per interagire con l'API. Lo scopo del client è gestire tutto questo gergo e facilitare l'utente nel processo di autenticazione. Poiché utilizzeremo un pacchetto fornito dal team dell'API WP REST, i dettagli sopra riportati verranno sottratti e potremo ottenere credenziali di token in un numero minimo di passaggi.

Nella discussione di cui sopra, ci siamo imbattuti in tre URI di endpoint, vale a dire:

  1. Endpoint richiesta di credenziali temporanee
  2. Endpoint di autorizzazione del proprietario di risorse
  3. Credenziali token Richiedi endpoint

Questi URI sono forniti dal server in vari modi. Uno di questi modi è esponendoli alla risposta del server durante il controllo dell'API. L'API di autenticazione OAuth per API REST di WordPress utilizza lo stesso metodo, come vedremo nella prossima sezione.

Dopo aver esaminato come funziona OAuth, il nostro prossimo passo è installare e abilitare l'API di autenticazione OAuth per WordPress.

Installazione dell'API di autenticazione OAuth per WordPress

L'API di autenticazione OAuth per WordPress consente al server di accettare richieste autenticate mediante l'implementazione OAuth. È costruito sulla base delle specifiche di OAuth 1.0a e le estende con un parametro aggiuntivo-wp_scope-da inviare al Richiesta di credenziali temporanee endpoint. Il wp_scope parametro definisce l'ambito dell'accesso che viene concesso al client. Puoi trovare maggiori informazioni nella documentazione ufficiale su GitHub.

Il plug-in è disponibile su Github dal team di API REST di WP e supporta solo la versione 4.4 o successiva di WordPress.

Cerchiamo di clonare il plugin navigando verso / Wp-content / plugins / directory:

$ git clone https://github.com/WP-API/OAuth1.git

Al termine del download, attivare il plug-in usando la CLI di WP:

Il plugin $ wp attiva OAuth1

In alternativa, puoi anche attivarlo navigando nel tuo browser nella sezione dei plugin di amministrazione di WordPress se non desideri utilizzare la CLI di WP.

Questo è tutto ciò che è necessario per consentire al server di accettare OAuth come metodo di autorizzazione. La prossima cosa che dobbiamo fare è inviare una richiesta al server per verificare se l'API OAuth è pronta per essere utilizzata.

Valutare la disponibilità dell'API OAuth

Prima di iniziare l'handshake OAuth, dovremmo innanzitutto verificare se l'API è abilitata sul server. Questo è fatto inviando un semplice OTTENERE richiesta al/ Wp-JSON / endpoint e quindi analizzando la risposta inviata dal server.

Accendi il tuo client HTTP e invia una richiesta al / Wp-JSON / endpoint come segue:

OTTIENI http: // tuo-dev-server / wp-json /

Ciò restituirà una risposta JSON come segue:

Il nostro obiettivo qui è il OAuth1 valore nel autenticazione costo dell'immobile. Questo oggetto ha le seguenti proprietà definite:

  • richiesta: l'endpoint della richiesta di credenziali temporanee
  • autorizzare: l'endpoint Autorizzazione proprietario risorsa
  • accesso: l'endpoint Richiesta token
  • versione: la versione di OAuth in uso

I primi tre di questi sono URL assoluti che abbiamo trovato quando abbiamo imparato a conoscere il meccanismo OAuth in una sezione precedente.

Il OAuth1 oggetto definito nel autenticazione il valore della proprietà mostra che l'API OAuth è stata abilitata con successo per il nostro sito WordPress e possiamo iniziare a usarla.

Se l'API OAuth non è abilitata per un sito, la risposta del server conterrà un vuoto autorizzazione valore della proprietà come segue:

Ora che abbiamo installato il plugin OAuth1.0a, vediamo come possiamo creare e gestire i consumatori per le nostre applicazioni.

Creare e gestire applicazioni

Una volta che il plugin OAuth1.0 è stato installato con successo, possiamo creare e gestire i consumatori per le nostre applicazioni andando all'amministratore di WordPress e poi al Utenti> Applicazioni pagina.

Su questo Applicazioni registrate pagina, possiamo registrare una nuova applicazione facendo clic sul pulsante Aggiungi nuovo e compilando i seguenti tre campi nella pagina risultante:

  1. Nome del consumatore: Il nome del consumatore. Questo nome viene mostrato all'utente durante il processo di autorizzazione e in seguito, nelle pagine del profilo sotto il Applicazioni autorizzate sezione.
  2. Descrizione: La descrizione facoltativa per l'applicazione consumer.
  3. URL di richiamata: L'URL di richiamata. Questo URL di callback viene utilizzato durante la generazione di credenziali temporanee, come vedremo nel passaggio successivo.

Una volta creato facendo clic sul Salva consumatore pulsante, il Chiave del cliente e Client Secret i parametri appariranno in fondo alla pagina per questo particolare consumatore.

Questi Chiave del cliente e Client Secret i parametri agiscono come oauth_consumer_keyoauth_consumer_secret parametri rispettivamente.

Nuovo Client Secret può essere creato facendo clic sul Rigenera segreto pulsante nella parte inferiore della pagina.

Il plugin OAuth espone anche la funzionalità per la creazione di un utente nella console tramite il plugin CLI WP. Quindi un nuovo utente può anche essere creato dal seguente comando nel terminale:

wp oauth1 add --name = --descrizione =

Questo consumatore appena creato apparirà sul Applicazioni registrate pagina in cui è possibile modificarlo.

Dopo aver registrato la nostra applicazione, siamo ora pronti per iniziare il processo di autorizzazione OAuth nelle seguenti sezioni.

Installazione del pacchetto CLI del client

Si noti che al momento della stesura di questo tutorial, il plugin OAuth1.0a non supporta più il pacchetto CLI del client. Il pacchetto CLI del client potrebbe essere aggiornato nel prossimo futuro per funzionare con l'ultima versione del plug-in OAuth, ma per il momento, fare riferimento alla sezione successiva sulla generazione di credenziali OAuth utilizzando un client HTTP.

Il pacchetto Client-CLI del team dell'API WP REST consente l'interazione remota con un sito WordPress utilizzando le API WP-CLI e WP REST. La fonte può essere trovata su GitHub.

Per utilizzare questo pacchetto, è necessario che il seguente sia installato e attivato sul server in cui si trova l'installazione di WordPress:

  1. WP CLI
  2. Plugin API REST WP
  3. Plugin server OAuth 1.0a

Sulla macchina (o sul client), da cui si desidera generare richieste, è necessario installare quanto segue:

  1. WP CLI
  2. Compositore
  3. Il repository CLI del client stesso

Puoi trovare le istruzioni per installare i pacchetti di cui sopra sui rispettivi siti.

Detto ciò, cloniamo il repository sul client eseguendo il seguente comando:

$ git clone https://github.com/WP-API/client-cli

Ora naviga nella directory clonata e installa le dipendenze del pacchetto usando Composer:

$ cd client-cli $ compositore di installazione

Se tutto va bene, la riga di comando dovrebbe mostrare qualcosa di simile al seguente:

Ora che abbiamo installato il pacchetto, siamo pronti a generare credenziali per i token e a interagire in remoto con l'API REST di WordPress usando OAuth.

Utilizzo della CLI del client per generare credenziali OAuth

Per avviare il processo di autorizzazione OAuth, otteniamo innanzitutto quanto segue dal server:

  • oauth_consumer_key
  • oauth_consumer_secret

Questo può essere generato indirizzando il terminale nella directory di installazione di WordPress sul server ed eseguendo il seguente comando CLI WP:

$ wp oauth1 add

Questo genererà un output simile al seguente:

Il ChiaveSegreto ottenuto qui sono i oauth_consumer_keyoauth_consumer_secret rispettivamente.

Ora dobbiamo collegare il client al nostro sito WordPress. Sul client, accedere a client-cli directory che hai clonato nella sezione precedente ed esegui il seguente comando:

$ wp --require = client.php api oauth1 collega http: // tuo-dev-server / --key = --= segreti

Sostituisci l'URL e anche la chiave e il segreto che hai ottenuto nel passaggio precedente nel comando precedente. L'output dovrebbe essere come il seguente:

$ wp --require = client.php api oauth1 connetti http: // localserver / wordpress-api / --key = kXZMTt3O5hBZ --secret = ueDNeCfgNuyNyxkiU3qHGgWZWggsg5lZwmMyhyjANsyYgz3Q Apri nel tuo browser: http: // localserver / wordpress-api / oauth1 / authorize ? oauth_token = wFxrd8OzcIL6lSRkLmmvViIe Inserisci il codice di verifica:

Passare all'URL fornito dal server e autenticarsi facendo clic su Autorizzare pulsante:

Ti verrà presentato il token di verifica (o il file oauth_verifier) nella schermata successiva:

Copia il verificatore e incollalo nel tuo terminale. Ti verrà dato un Chiave e a Segreto, che sono fondamentalmente tuoi oauth_tokenoauth_token_secret rispettivamente:

È possibile utilizzare queste credenziali di token nel client HTTP o in qualsiasi altra applicazione che supporti l'invio di richieste autenticate utilizzando l'API OAuth.

Utilizzo di un client HTTP per generare credenziali OAuth

Poiché il plug-in del server OAuth 1.0a segue il flusso a tre gambe, la generazione delle credenziali OAuth prevede tre passaggi:

  1. Acquisizione di credenziali temporanee
  2. Autorizzazioni utente
  3. Scambio di pedine

Iniziamo ad implementare ciascuno dei passaggi precedenti utilizzando un client HTTP, ad esempio Postman.

1. Acquisizione di credenziali temporanee

Per acquisire credenziali temporanee, inviamo un INVIARE richiesta al / OAuth1 / richiesta endpoint. Questo endpoint di richiesta di credenziali temporanee deve essere rilevato automaticamente poiché un server potrebbe sostituire questa route con la propria. Abbiamo esaminato la funzione di individuazione automatica durante la valutazione della disponibilità dell'API OAuth in una sezione precedente.

Il INVIARE richiesta dovrebbe includere il oauth_consumer_keyoauth_consumer_secret parametri acquisiti al momento della registrazione di un consumatore per l'applicazione. La richiesta potrebbe anche includere il oauth_callback parametro e questo URL di richiamata deve corrispondere allo schema, all'host, alla porta e al percorso dell'URL di richiamata fornito al momento della registrazione dell'applicazione.

Oltre al oauth_consumer_keyoauth_consumer_secret parametri, la richiesta dovrebbe includere anche oauth_signatureoauth_signature_method parametri. Quando si usa Postman, il oauth_signature viene generato automaticamente e abbiamo solo bisogno di specificare il oauth_signature_method parametro. Attualmente, solo il HMAC-SHA1 il metodo di firma è supportato dal plugin del server OAuth.

I parametri precedenti possono essere passati in uno dei seguenti tre modi:

  1. attraverso Autorizzazione intestazione
  2. Attraverso (OTTENERE) parametri di query nell'URL
  3. Attraverso (INVIARE) richiesta parametri del corpo. Il tipo di contenuto in questo caso dovrebbe essere application / x-www-form-urlencoded.

Spetta a te utilizzare uno di questi metodi sopra per inviare questi parametri al server.

Iniziamo ora il processo sparando su Postman e inviando un INVIARE richiesta all'endpoint della richiesta di credenziali temporanee. Ma prima, copia il Chiave del consumatore e Segreto dei consumatori parametri forniti dalla nuova applicazione come saranno necessari in questo passaggio.

Configurare Postman per inviare a INVIARE richiesta all'endpoint delle credenziali temporanee dei token. Quindi nel Autorizzazione scheda, selezionare il OAuth 1.0 opzione dal menu a discesa. Compila il Chiave del consumatore e Segreto dei consumatori campi con i valori forniti dal consumatore. Assicurati di controllare che il Metodo di firma l'opzione è impostata su HMAC-SHA1.

Non è necessario inserire valori diversi da questi. Clicca il Richiesta di aggiornamento pulsante e infine inviare la richiesta facendo clic su Inviare pulsante.

Se non ci sono errori, il server restituirà a 200 - OK codice di stato insieme al corpo della risposta con un tipo di contenuto di application / x-www-form-urlencoded. Questo corpo di richiesta ha un aspetto simile alla seguente stringa di testo:

oauth_token = tyNCKaL3WAJXib5SI6jCnr4P & oauth_token_secret = 1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF & oauth_callback_confirmed = true

Questo corpo di risposta contiene tre parametri per la fase successiva del flusso a tre gambe. Questi tre parametri sono:

  1. oauth_token: Un token OAuth temporaneo per la fase di autorizzazione.
  2. oauth_token_secret: Un segreto temporaneo da utilizzare insieme oauth_token.
  3. oauth_callback_confirmed: Questo parametro viene sempre restituito indipendentemente dal fatto che tu fornisca o meno oauth_callback parametro nel primo passaggio.

Con queste credenziali temporanee pronte, siamo pronti per la fase di autorizzazione dell'utente.

2. Autorizzazione dell'utente

Per la fase di autorizzazione dell'utente, apriamo l'endpoint di autorizzazione del proprietario della risorsa nel browser e passiamo il oauth_tokenoauth_token_secret come ottenuto nel passaggio precedente come parametri di query come il seguente:

http: // your-dev-Server / OAuth1 / autorizzare oauth_token =& Oauth_token_secret =

Il browser ti chiederà di accedere a WordPress (se non hai già effettuato l'accesso) e poi ti chiederà di autorizzare l'applicazione:

Qui Impressionante applicazione è il nome dell'applicazione registrata.

Autorizza l'applicazione facendo clic su Autorizzare pulsante e ti verrà presentato un token di verifica nella schermata successiva:

Questo token funge da oauth_verifier gettone nel passaggio successivo.

Una volta che l'utente ha autorizzato il client, l'applicazione verrà visualizzata sotto Applicazioni autorizzate sezione sul Utenti> Il tuo profilo pagina.

3. Scambio di token

Il passaggio successivo e finale nel flusso a tre gambe è lo scambio di token. In questo passaggio, i token temporanei ottenuti nel primo passaggio vengono scambiati per un token longevo che potrebbe essere utilizzato dal client.

Per avviare il processo di scambio di token, tornare a Postman e configurarlo per inviare a INVIARE richiesta all'endpoint della richiesta del token.

Usando il OAuth 1.0 opzione di nuovo nel Autorizzazione scheda, compilare i campi per Chiave del consumatore e Segreto dei consumatori con valori forniti dal consumatore. Per il Gettone e Token Secret campi, utilizzare i valori di oauth_tokenoauth_token_secret parametri (credenziali temporanee) che sono stati ottenuti nel primo passaggio.

Poiché possiamo anche passare parametri nell'URL come parametri di query, aggiungere il oauth_verifier parametro per l'URL come segue:

http: // your-dev-Server / OAuth1 / accesso oauth_verifier =

Con tutti i parametri in atto, inviare la richiesta facendo clic su Inviare pulsante. Se tutto va bene, il server restituirà a 200 - OK codice di stato insieme al corpo della risposta contenente oauth_tokenoauth_token_secret parametri.

oauth_token =& Oauth_token_secret =

A questo punto, i token temporanei acquisiti nel primo passaggio vengono scartati e non possono più essere utilizzati.

Questi nuovi oauth_tokenoauth_token_secret i parametri sono le tue credenziali OAuth che puoi utilizzare nel tuo client per generare richieste autenticate.

Invio di una richiesta autenticata di prova

Ora che abbiamo ottenuto le credenziali del token, possiamo inviare una richiesta di test al server usando Postman per vedere se funzionano (ovviamente lo faranno!).

Invieremo un ELIMINA richiesta al server di eliminare un post con un id di 50. Questo ID può essere diverso nel tuo caso.

Avrai bisogno di avere quanto segue prima di iniziare:

  • oauth_consumer_key: ottenuto nel primo passaggio
  • oauth_consumer_secret: ottenuto nel primo passaggio
  • oauth_token: ottenuto nel passaggio finale
  • oauth_token_secret: ottenuto nel passaggio finale

Selezionare OAuth 1.0 dal menu a discesa sotto il Autorizzazione scheda in Postman e riempire i primi quattro campi come menzionato sopra. Di seguito è come appare:

Clicca il Richiesta di aggiornamento pulsante dopo aver compilato i campi. Controllo del Aggiungi parametri all'intestazione opzione invia i parametri nell'intestazione della richiesta anziché aggiungerli in una stringa di query.

Invia la richiesta e dovresti ottenere un 200 - OK codice di stato dal server, che mostra che il post è stato cancellato con successo.

Conclusione

In questo lungo tutorial abbiamo preso una panoramica del metodo di autenticazione OAuth e di come funziona per fornire un accesso delegato sicuro a applicazioni e servizi di terze parti. Abbiamo anche configurato l'API di autenticazione OAuth per WordPress sul server e l'abbiamo utilizzata in combinazione con un client HTTP per ottenere credenziali di token.

Nella parte successiva di questa serie, esamineremo il recupero dei contenuti tramite l'API REST di WP. Quindi rimani sintonizzato ...