O que significa usar o WordPress como proxy?
Se você já trabalhou com o WordPress por algum tempo, especialmente quando se trata de usar algum tipo de funcionalidade do Ajax, provavelmente já ouviu a frase “usar o WordPress como proxy" em algum momento.
E mesmo que você não tenha, as chances de que você realmente fez isso são muito altas.
Embora eu ache que, à medida que o tempo avança, veremos eventualmente a API REST substituir as formas tradicionais que usamos o Ajax, mas essa é provavelmente uma história diferente para outra hora.
Então, o que significa usar o WordPress como proxy sempre que você estiver trabalhando com solicitações Ajax? Requer um pouco de compreensão das solicitações entre sites, como funciona o roteamento de uma solicitação pelo WordPress e, em seguida, analisa a resposta.
Use o WordPress como um proxy
É um post um pouco longo, não é? Em vez disso, tentarei dividi-lo em termos mais curtos para que você possa lê-lo e depois voltar ao trabalho.
Como procurador
Primeiro, pegue a definição de um proxy :
a autoridade para representar outra pessoa, especialmente na votação
Se você clicar no link acima, notará que existem algumas outras definições, mas nenhuma delas é realmente suficiente. Em vez disso, gosto de pensar neles um pouco mais no abstrato, pelo menos no que diz respeito ao software.
Para os propósitos deste post, digamos que o WordPress seja um proxy para uma solicitação, o que significa que é responsável por servir de intermediário entre o início da solicitação e a resposta a ela.
Resumidamente,
O WordPress funciona como um proxy roteando uma solicitação para outro serviço e capturando sua resposta.
Talvez você já tenha ouvido algo parecido, talvez não. Independentemente disso, é assim que pode parecer em alto nível:
Agora, quando você precisar fazer uma solicitação assíncrona (ou uma solicitação Ajax, como usarei no restante deste post), você terá uma das duas opções:
- faça a solicitação para uma página que existe dentro do WordPress,
- faça a solicitação para uma página que existe em outro domínio.
Se você estiver fazendo solicitações para páginas que existem em seu aplicativo (leia-se: dentro do WordPress), não terá problemas.
Sobre a segurança dos pedidos
Mas fazer solicitações Ajax fora do seu próprio domínio é impossível. Isso ocorre porque se destina a proteger XSS e CSRF.
Em suma, cada um deles se refere ao seguinte, respectivamente:
Os ataques XSS ocorrem quando um invasor usa um aplicativo da Web para enviar código malicioso, geralmente na forma de um script do lado do navegador, para um usuário final diferente
e:
Cross-Site Request Forgery (CSRF) é um ataque que força um usuário final a executar ações indesejadas em um aplicativo da Web no qual ele está autenticado no momento.
Em resumo, é por isso que precisamos usar o WordPress como proxy. Naturalmente, porém, isso levanta a questão de como?
Usando o WordPress como um proxy
Para fazer isso, você precisará de várias coisas:
- uma página que sua solicitação Ajax pode consultar,
- uma função para capturar a solicitação ajax e enviá-la para a URL adequada,
- uma maneira de o lado do servidor analisar a resposta,
- uma função para retornar os dados para a função Ajax original.
Novamente, por uma questão de espaço, não fornecerei um exemplo aprofundado disso, mas deve ser suficiente para você começar.
Primeiro, você precisa ter certeza de ter uma função definida para capturar sua solicitação Ajax. Já existe muita documentação sobre isso no Codex. Um exemplo simples disso ficaria assim:
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
});
};
Em seguida, você precisa de uma página no servidor para fazer uma solicitação à URL que contém seus dados. Isso pode ser feito usando cURL, isso pode ser feito usando file_get_contents e isso pode ser feito por outros meios.
Como não sei nem quero fornecer um exemplo prescritivo, compartilharei uma demonstração muito simples de como isso pode funcionar (pelo menos nos estágios iniciais ):
<?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();
}
Ao receber uma resposta, você pode optar por analisá-la no lado do servidor (o que eu recomendo) e retorná-la usando um formato leve para a função JavaScript original, conforme visto acima. Observe que estou usando json_encode no código acima.
A partir daí, você pode fazer o que for necessário na página em questão com os dados que possui. Observe que as informações estão contidas no objeto de resposta e talvez seja necessário inspecionar o que ele contém para tratá-las adequadamente. Isso é realizado e demonstrado no código acima.
Mas os detalhes disso dependerão muito do que você deseja alcançar.
WordPress como proxy
Por fim, o fluxo de controle se parece com isto:
O objetivo de todos os itens acima é ajudar a fornecer um pouco de fundo sobre o motivo pelo qual você pode ver alguns dos códigos que você faz, bem como por que você precisa estruturar seu código assim.