Que signifie utiliser WordPress comme proxy ?

Si vous avez travaillé avec WordPress pendant un certain temps, en particulier lorsqu’il s’agit d’utiliser certains types de fonctionnalités Ajax, vous avez probablement entendu l’expression "utiliser WordPress comme proxy" à un moment donné.

Et même si vous ne l’avez pas fait, les chances que vous l’ayez réellement fait sont assez élevées.

Bien que je pense qu’au fil du temps, nous verrons éventuellement l’API REST remplacer les méthodes traditionnelles d’utilisation d’Ajax, mais c’est probablement une autre histoire pour une autre fois.

Alors, qu’est-ce que cela signifie d’utiliser WordPress comme proxy chaque fois que vous travaillez avec des requêtes Ajax? Cela nécessite un peu de compréhension des requêtes intersites, du fonctionnement du routage d’une requête via WordPress, puis de l’analyse de la réponse.

Utiliser WordPress comme proxy

C’est un peu long, n’est-ce pas? Au lieu de cela, je vais essayer de le décomposer en termes plus courts afin que vous puissiez le lire puis vous remettre au travail.

En tant que mandataire

Prenons d’ abord la définition d’un proxy :

le pouvoir de représenter quelqu’un d’autre, en particulier lors du vote

Si vous cliquez sur le lien ci-dessus, vous remarquerez qu’il existe quelques autres définitions, mais aucune d’entre elles ne suffit vraiment. Au lieu de cela, j’aime penser à eux un peu plus dans l’abstrait, du moins en ce qui concerne les logiciels.

Pour les besoins de cet article, disons que WordPress est un proxy pour une requête, ce qui signifie qu’il est chargé de servir d’intermédiaire entre le début de la requête et la réponse à celle-ci.

Bref,

WordPress sert de proxy en acheminant une requête vers un autre service et en capturant sa réponse.

Peut-être avez-vous entendu quelque chose de similaire, peut-être pas. Quoi qu’il en soit, voici à quoi cela pourrait ressembler à un niveau élevé:

Maintenant, lorsque vous devez faire une requête asynchrone (ou une requête Ajax comme je l’utiliserai dans le reste de cet article), vous avez alors l’une des deux options :

1. faire la demande à une page qui existe dans WordPress,
2. faire la demande à une page qui existe sur l’autre domaine.

Si vous faites des requêtes sur des pages qui existent dans votre application (lire: dans WordPress), vous n’aurez aucun problème.

Sur la sécurité des demandes

Mais faire des requêtes Ajax en dehors de votre propre domaine est interdit. En effet, il est destiné à protéger XSS et CSRF.

En bref, chacun d’eux se réfère respectivement à ce qui suit :

Les attaques XSS se produisent lorsqu’un attaquant utilise une application Web pour envoyer un code malveillant, généralement sous la forme d’un script côté navigateur, à un autre utilisateur final.

et:

Cross-Site Request Forgery (CSRF) est une attaque qui force un utilisateur final à exécuter des actions indésirables sur une application Web dans laquelle il est actuellement authentifié.

Voilà, en bref, pourquoi nous devons utiliser WordPress comme proxy. Naturellement, cependant, cela soulève la question de savoir comment?

Utiliser WordPress comme proxy

Pour ce faire, vous aurez besoin de plusieurs choses :

1.  une page que votre requête Ajax peut interroger,
2. une fonction pour intercepter la requête ajax et l’envoyer à la bonne URL,
3. un moyen pour le côté serveur d’analyser la réponse,
4. une fonction pour renvoyer les données à la fonction Ajax d’origine.

Encore une fois, par souci d’espace, je ne fournirai pas d’exemple détaillé de cela, mais cela devrait suffire à vous aider à démarrer.

Tout d’abord, vous devez vous assurer que vous disposez d’une fonction définie pour intercepter votre requête Ajax. Il y a déjà beaucoup de documentation à ce sujet dans le Codex. Un exemple simple de ceci ressemblerait à ceci:

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

Ensuite, vous avez besoin d’une page sur le serveur pour faire une demande à l’URL qui contient vos données. Cela peut être fait en utilisant cURL, cela peut être fait en utilisant file_get_contents, et cela peut être fait par d’autres moyens.

Parce que je ne sais pas et que je ne veux pas fournir d’exemple normatif, je vais partager une démonstration très simple de la façon dont cela pourrait fonctionner (au moins dans les premières étapes ):

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

Lorsque vous recevez une réponse, vous pouvez choisir de l’analyser côté serveur (ce que je recommande) et de la renvoyer en utilisant un format léger à la fonction JavaScript d’origine, comme indiqué ci-dessus. Notez que j’utilise json_encode dans le code ci-dessus.

À partir de là, vous pouvez ensuite faire tout ce que vous devez faire sur la page en question avec les données dont vous disposez. Notez que les informations sont contenues dans l’objet de réponse et que vous devrez peut-être inspecter ce qu’il contient afin de le gérer correctement. Ceci est accompli et démontré dans le code ci-dessus.

Mais les détails de cela dépendront fortement de ce que vous cherchez à réaliser.

WordPress en tant que proxy

En fin de compte, le flux de contrôle ressemble à ceci :

Le but de tout ce qui précède est d’aider à fournir un peu d’information sur les raisons pour lesquelles vous pouvez voir une partie du code que vous faites ainsi que sur la raison pour laquelle vous devez structurer votre code de cette manière.