Cosa significa utilizzare WordPress come proxy?
Se hai lavorato con WordPress per un certo periodo di tempo, specialmente quando si tratta di utilizzare qualche tipo di funzionalità Ajax, probabilmente a un certo punto avrai sentito la frase "usa WordPress come proxy".
E anche se non hai le probabilità di averlo effettivamente fatto sono piuttosto alte.
Anche se penso che, con il passare del tempo, alla fine vedremo l’API REST sostituire i modi tradizionali in cui abbiamo utilizzato Ajax, ma probabilmente è una storia diversa per un’altra volta.
Quindi cosa significa usare WordPress come proxy ogni volta che lavori con richieste Ajax? Richiede un po’ di comprensione delle richieste tra siti, come funziona l’instradamento di una richiesta tramite WordPress e quindi l’analisi della risposta.
Usa WordPress come proxy
È un post un po’ lungo, vero? Invece, cercherò di scomporlo in termini più brevi in modo che tu possa leggerlo e poi tornare al lavoro.
Come procuratore
Innanzitutto, prendi la definizione di proxy :
l’autorità di rappresentare qualcun altro, soprattutto nel voto
Se fai clic sul collegamento sopra, noterai che ci sono alcune altre definizioni ma nessuna di esse è davvero sufficiente. Invece, mi piace pensarli un po’ più in astratto, almeno per quanto riguarda il software.
Ai fini di questo post, diciamo che WordPress è un proxy per una richiesta, il che significa che è responsabile di fungere da intermediario tra l’inizio della richiesta e la risposta ad essa.
In breve,
WordPress funge da proxy instradando una richiesta a un altro servizio e catturandone la risposta.
Forse hai sentito qualcosa di simile, forse no. Indipendentemente da ciò, ecco come potrebbe apparire ad alto livello:
Ora, quando devi fare una richiesta asincrona (o una richiesta Ajax come userò nel resto di questo post), hai una delle due opzioni:
- effettuare la richiesta a una pagina esistente all’interno di WordPress,
- effettuare la richiesta a una pagina che esiste su un altro dominio.
Se stai facendo richieste a pagine che esistono all’interno della tua app (leggi: all’interno di WordPress), non avrai problemi.
Sulla sicurezza delle richieste
Ma fare richieste Ajax al di fuori del tuo dominio non è possibile. Questo perché ha lo scopo di proteggere XSS e CSRF.
In breve, ciascuno di questi si riferisce rispettivamente a quanto segue:
Gli attacchi XSS si verificano quando un utente malintenzionato utilizza un’applicazione Web per inviare codice dannoso, generalmente sotto forma di script lato browser, a un utente finale diverso
e:
Cross-Site Request Forgery (CSRF) è un attacco che costringe un utente finale a eseguire azioni indesiderate su un’applicazione Web in cui è attualmente autenticato.
Questo, in breve, è il motivo per cui dobbiamo usare WordPress come proxy. Naturalmente, però, questo solleva la domanda su come?
Utilizzo di WordPress come proxy
Per fare ciò, avrai bisogno di diverse cose:
- una pagina che la tua richiesta Ajax può interrogare,
- una funzione per catturare la richiesta ajax e inviarla all’URL corretto,
- un modo per il lato server di analizzare la risposta,
- una funzione per restituire i dati alla funzione Ajax originale.
Ancora una volta, per motivi di spazio, non fornirò un esempio approfondito di questo, ma dovrebbe essere sufficiente per iniziare.
Innanzitutto, devi assicurarti di avere una funzione impostata per catturare la tua richiesta Ajax. C’è già molta documentazione su questo nel Codex. Un semplice esempio di questo sarebbe simile a questo:
var _get_columns = function() {
// Don't forget to use a nonce or security value here.
var data = {
'action': 'get_all_columns'
'security': '<?php echo wp_create_nonce( "acme-security-ajax-nonce" ); ?>'
};
// TODO Check for error logging if the response value doesn't exist.
$.get( ajaxurl, data, function( response) {
response = $.parseJSON( response );
// Your custom functionality here
});
};
Successivamente, hai bisogno di una pagina sul server per effettuare una richiesta all’URL che contiene i tuoi dati. Questo potrebbe essere fatto usando cURL, questo potrebbe essere fatto usando file_get_contents e questo potrebbe essere fatto con altri mezzi.
Poiché non so né voglio fornire un esempio prescrittivo, condividerò una demo molto semplice di come potrebbe funzionare (almeno nelle fasi iniziali ):
<?php
add_action( 'wp_ajax_get_all_data', 'get_all_data' );
/**
* Retrieves the requested data from the specified URL
* returns the values in JSON.
*/
function get_all_data() {
// Note $url is up to you.
$curl = curl_init( $url );
curl_setopt( $curl, CURLOPT_RETURNTRANSFER, 1 );
curl_setopt( $curl, CURLOPT_HTTPAUTH, CURLAUTH_ANY );
curl_setopt( $curl, CURLOPT_SSL_VERIFYPEER, false );
curl_setopt( $curl, CURLOPT_FOLLOWLOCATION, true );
$response = curl_exec( $curl );
$resultStatus = curl_getinfo( $curl );
if( 200 !== $resultStatus['http_code']) {
echo 'Call Failed '.print_r( $result_status );
}
curl_close( $curl );
echo json_encode( utf8_encode( $response) );
wp_die();
}
Quando ricevi una risposta, puoi scegliere di analizzarla sul lato server (cosa che consiglio) e restituirla utilizzando un formato leggero alla funzione JavaScript originale come visto sopra. Nota che sto usando json_encode nel codice sopra.
Da lì, puoi quindi fare tutto ciò che devi fare sulla pagina in questione con i dati che hai. Si noti che le informazioni sono contenute nell’oggetto risposta e potrebbe essere necessario ispezionare ciò che contiene per gestirlo correttamente. Ciò viene realizzato e viene illustrato nel codice sopra.
Ma i dettagli di questo dipenderanno fortemente da ciò che stai cercando di ottenere.
WordPress come proxy
In definitiva, il flusso di controllo è simile a questo:
Il punto di tutto quanto sopra è aiutare a fornire un po ‘di background sul motivo per cui potresti vedere parte del codice che fai e perché devi strutturare il tuo codice in questo modo.