Vad innebär det att använda WordPress som proxy?

Om du har arbetat med WordPress hur länge som helst, särskilt när det gäller att använda någon typ av Ajax-funktionalitet, har du förmodligen hört frasen "använd WordPress som proxy" någon gång.

Och även om du inte har chansen att du faktiskt har gjort det är det ganska höga.

Även om jag tror att när tiden går framåt kommer vi så småningom att se REST API ersätta de traditionella sätten som vi har använt Ajax, men det är förmodligen en annan historia för en annan gång.

Så vad betyder det att använda WordPress som proxy när du arbetar med Ajax-förfrågningar? Det kräver lite förståelse för förfrågningar mellan webbplatser, hur dirigering av en förfrågan via WordPress fungerar och sedan analysera svaret.

Använd WordPress som proxy

Det är ett lite långt inlägg, eller hur? Istället ska jag försöka bryta ner det i kortare termer så att du kan läsa det och sedan börja jobba igen.

Som ombud

Ta först definitionen av en proxy :

befogenhet att företräda någon annan, särskilt vid röstning

Om du klickar på länken ovan kommer du att märka att det finns några andra definitioner men ingen av dem räcker egentligen. Istället tycker jag om att tänka på dem lite mer abstrakt, åtminstone när det gäller mjukvara.

För detta inläggs syften, låt oss säga att WordPress är en proxy för en förfrågan, vilket betyder att den är ansvarig för att fungera som en mellanhand mellan början av förfrågan och svaret på den.

Kortfattat,

WordPress fungerar som en proxy genom att dirigera en förfrågan till en annan tjänst och fånga dess svar.

Kanske har du hört något liknande, kanske inte. Oavsett så kan det se ut så här på hög nivå:

Nu, när du behöver göra en asynkron förfrågan (eller en Ajax-förfrågan som jag kommer att använda genom resten av det här inlägget), så har du ett av två alternativ:

1. skicka begäran till en sida som finns i WordPress,
2. skicka begäran till en sida som finns på den andra domänen.

Om du gör förfrågningar till sidor som finns i din app (läs: inom WordPress) har du inga problem.

Om säkerheten för förfrågningar

Men att göra Ajax-förfrågningar utanför din egen domän är en no-go. Detta beror på att det är tänkt att skydda XSS och CSRF.

I korthet hänvisar var och en av dessa till följande:

XSS-attacker uppstår när en angripare använder en webbapplikation för att skicka skadlig kod, vanligtvis i form av ett webbläsarskript, till en annan slutanvändare

och:

Cross-Site Request Forgery (CSRF) är en attack som tvingar en slutanvändare att utföra oönskade åtgärder på en webbapplikation där de för närvarande är autentiserade.

Det är kort sagt därför vi behöver använda WordPress som proxy. Men naturligtvis väcker detta frågan om hur?

Använda WordPress som proxy

För att göra detta behöver du flera saker:

1.  en sida som din Ajax-förfrågan kan fråga,
2. en funktion för att fånga ajax-förfrågan och skicka den till rätt URL,
3. ett sätt för serversidan att analysera svaret,
4. en funktion för att återställa data till den ursprungliga Ajax-funktionen.

Återigen, för utrymmets skull kommer jag inte att ge ett djupgående exempel på detta men det borde räcka för att du ska komma igång.

Först måste du se till att du har en funktion inställd för att fånga din Ajax-förfrågan. Det finns redan massor av dokumentation kring detta i Codex. Ett enkelt exempel på detta skulle se ut så här:

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
    });
};

Därefter behöver du en sida på servern för att göra en förfrågan till URL:en som har dina data. Detta kan göras med cURL, detta kan göras med file_get_contents, och detta kan göras på andra sätt.

Eftersom jag inte vet eller vill ge ett föreskrivande exempel, kommer jag att dela en mycket enkel demonstration av hur detta kan fungera (åtminstone i de tidiga stadierna ):

<?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();
}

När du får ett svar kan du välja att analysera det på serversidan (vilket jag rekommenderar) och returnera det med ett lätt format till den ursprungliga JavaScript-funktionen som ses ovan. Lägg märke till att jag använder json_encode i koden ovan.

Därifrån kan du sedan göra vad du än behöver göra med den aktuella sidan med den data du har. Observera att informationen finns i svarsobjektet och du kan behöva inspektera vad den innehåller för att kunna hantera den korrekt. Detta uppnås och visas i koden ovan.

Men detaljerna i detta kommer att bero mycket på vad du vill uppnå.

WordPress som proxy

I slutändan ser kontrollflödet ut ungefär så här:

Poängen med allt ovan är att hjälpa till att ge lite bakgrund till varför du kan se en del av koden du gör samt varför du behöver strukturera din kod så här.