¿Qué significa usar WordPress como proxy?
Si ha trabajado con WordPress durante algún tiempo, especialmente cuando se trata de usar algún tipo de funcionalidad Ajax, es probable que haya escuchado la frase "usar WordPress como proxy" en algún momento.
E incluso si no lo has hecho, las probabilidades de que realmente lo hayas hecho son bastante altas.
Aunque creo que, a medida que avanza el tiempo, finalmente veremos que la API REST reemplaza las formas tradicionales en que hemos usado Ajax, pero es probable que esa sea una historia diferente para otro momento.
Entonces, ¿qué significa usar WordPress como proxy cada vez que trabaja con solicitudes de Ajax? Requiere un poco de comprensión de las solicitudes entre sitios, cómo funciona el enrutamiento de una solicitud a través de WordPress y luego analizar la respuesta.
Usar WordPress como proxy
Esa es una publicación un poco larga, ¿no? En cambio, intentaré dividirlo en términos más cortos para que pueda leerlo y luego volver al trabajo.
como representante
Primero, tome la definición de un proxy :
la autoridad para representar a otra persona, especialmente en la votación
Si hace clic en el enlace anterior, notará que hay algunas otras definiciones, pero ninguna de ellas es realmente suficiente. En cambio, me gusta pensar en ellos un poco más en abstracto, al menos en lo que respecta al software.
Para los propósitos de esta publicación, digamos que WordPress es un proxy para una solicitud, lo que significa que es responsable de servir como intermediario entre el inicio de la solicitud y la respuesta a la misma.
En breve,
WordPress sirve como proxy al enrutar una solicitud a otro servicio y capturar su respuesta.
Tal vez hayas escuchado algo similar, tal vez no. Independientemente, así es como podría verse a un alto nivel:
Ahora, cuando necesite realizar una solicitud asíncrona (o una solicitud Ajax como usaré en el resto de esta publicación), entonces tiene una de dos opciones:
- hacer la solicitud a una página que existe dentro de WordPress,
- haga la solicitud a una página que existe en el otro dominio.
Si realiza solicitudes a páginas que existen dentro de su aplicación (léase: dentro de WordPress), no tendrá ningún problema.
Sobre la seguridad de las solicitudes
Pero hacer solicitudes de Ajax fuera de su propio dominio es imposible. Esto se debe a que está destinado a proteger XSS y CSRF.
En resumen, cada uno de estos se refiere a lo siguiente, respectivamente:
Los ataques XSS ocurren cuando un atacante usa una aplicación web para enviar código malicioso, generalmente en forma de un script del lado del navegador, a un usuario final diferente.
y:
La falsificación de solicitud entre sitios (CSRF) es un ataque que obliga a un usuario final a ejecutar acciones no deseadas en una aplicación web en la que está autenticado actualmente.
En resumen, es por eso que necesitamos usar WordPress como proxy. Naturalmente, sin embargo, esto plantea la pregunta de ¿cómo?
Usar WordPress como un proxy
Para hacer esto, necesitarás varias cosas:
- una página que su solicitud de Ajax puede consultar,
- una función para capturar la solicitud ajax y enviarla a la URL adecuada,
- una forma para que el lado del servidor analice la respuesta,
- una función para devolver los datos a la función Ajax original.
Una vez más, por razones de espacio, no proporcionaré un ejemplo detallado de esto, pero debería ser suficiente para comenzar.
Primero, debe asegurarse de tener una función configurada para capturar su solicitud de Ajax. Ya hay mucha documentación sobre esto en el Codex. Un ejemplo simple de esto se vería así:
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
});
};
A continuación, necesita una página en el servidor para realizar una solicitud a la URL que tiene sus datos. Esto se puede hacer usando cURL, esto se puede hacer usando file_get_contents, y esto se puede hacer a través de otros medios.
Como no sé ni quiero proporcionar un ejemplo prescriptivo, compartiré una demostración muy simple de cómo podría funcionar esto (al menos en las primeras etapas ):
<?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();
}
Cuando recibe una respuesta, puede optar por analizarla en el lado del servidor (lo que recomiendo) y devolverla usando un formato ligero a la función de JavaScript original como se ve arriba. Tenga en cuenta que estoy usando json_encode en el código anterior.
A partir de ahí, puede hacer lo que sea necesario en la página en cuestión con los datos que tiene. Tenga en cuenta que la información está contenida en el objeto de respuesta y es posible que deba inspeccionar lo que contiene para manejarlo correctamente. Esto se logra y se demuestra en el código anterior.
Pero los detalles de esto dependerán en gran medida de lo que esté buscando lograr.
WordPress como proxy
En última instancia, el flujo de control se parece a esto:
El objetivo de todo lo anterior es ayudar a proporcionar un poco de información sobre por qué puede ver parte del código que hace y por qué necesita estructurar su código de esta manera.