Если вы работали с WordPress какое-то время, особенно когда речь идет об использовании некоторых функций Ajax, то вы, вероятно, слышали фразу «использовать WordPress в качестве прокси».
И даже если у вас нет шансов, что вы действительно это сделали, довольно высоки.
Хотя я думаю, что с течением времени мы в конечном итоге увидим, как REST API заменит традиционные способы, которыми мы использовали Ajax, но это, вероятно, другая история в другой раз.
Так что же означает использование WordPress в качестве прокси всякий раз, когда вы работаете с Ajax-запросами? Это требует некоторого понимания межсайтовых запросов, того, как работает маршрутизация запроса через WordPress, а затем анализа ответа.
Используйте WordPress в качестве прокси
Это немного длинный пост, не так ли? Вместо этого я попытаюсь разбить его на более короткие термины, чтобы вы могли прочитать его, а затем вернуться к работе.
Как прокси
Сначала возьмем определение прокси :
право представлять кого-то другого, особенно при голосовании
Если вы нажмете на ссылку выше, вы заметите, что есть несколько других определений, но ни одно из них не является достаточным. Вместо этого мне нравится думать о них более абстрактно, по крайней мере, в том, что касается программного обеспечения.
Для целей этого поста предположим, что WordPress является прокси для запроса, что означает, что он отвечает за то, чтобы служить посредником между началом запроса и ответом на него.
Короче говоря,
WordPress служит прокси-сервером, перенаправляя запрос другому сервису и перехватывая его ответ.
Может быть, вы слышали что-то подобное, а может и нет. Тем не менее, вот как это могло бы выглядеть на высоком уровне:
Теперь, когда вам нужно сделать асинхронный запрос (или запрос Ajax, который я буду использовать в оставшейся части этого поста), у вас есть один из двух вариантов:
- сделать запрос на страницу, которая существует в WordPress,
- сделать запрос на страницу, которая существует на другом домене.
Если вы делаете запросы к страницам, которые существуют в вашем приложении (читай: в WordPress), у вас не возникнет проблем.
О безопасности запросов
Но делать Ajax-запросы за пределами вашего собственного домена нельзя. Это потому, что он предназначен для защиты XSS и CSRF.
Короче говоря, каждый из них относится к следующему, соответственно:
Атаки XSS происходят, когда злоумышленник использует веб-приложение для отправки вредоносного кода, как правило, в виде сценария на стороне браузера, другому конечному пользователю.
а также:
Подделка межсайтовых запросов (CSRF) — это атака, которая заставляет конечного пользователя выполнять нежелательные действия в веб-приложении, в котором он в настоящее время аутентифицирован.
Короче говоря, именно поэтому нам нужно использовать WordPress в качестве прокси. Однако, естественно, возникает вопрос, как?
Использование WordPress в качестве прокси
Для этого вам понадобится несколько вещей:
- страница, которую может запрашивать ваш Ajax-запрос,
- функция для перехвата запроса ajax и отправки его на правильный URL,
- способ для серверной стороны проанализировать ответ,
- функция для возврата данных исходной функции Ajax.
Опять же, для экономии места я не буду приводить подробный пример этого, но этого должно быть достаточно, чтобы вы начали.
Во-первых, вам нужно убедиться, что у вас установлена функция для перехвата вашего Ajax-запроса. В Кодексе уже есть много документации по этому поводу. Простой пример этого будет выглядеть так:
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
});
};
Затем вам нужна страница на сервере, чтобы сделать запрос к URL-адресу, на котором есть ваши данные. Это можно сделать с помощью cURL, это можно сделать с помощью file_get_contents, а также с помощью других средств.
Поскольку я не знаю и не хочу приводить предписывающий пример, я поделюсь очень простой демонстрацией того, как это может работать (по крайней мере, на ранних стадиях ):
<?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();
}
Когда вы получаете ответ, вы можете проанализировать его на стороне сервера (что я рекомендую) и вернуть его, используя облегченный формат, в исходную функцию JavaScript, как показано выше. Обратите внимание, что я использую json_encode в приведенном выше коде.
Оттуда вы можете делать все, что вам нужно, с соответствующей страницей с данными, которые у вас есть. Обратите внимание, что информация содержится в объекте ответа, и вам может потребоваться проверить, что он содержит, чтобы правильно с ним обращаться. Это достигается и демонстрируется в приведенном выше коде.
Но детали этого будут сильно зависеть от того, чего вы хотите достичь.
WordPress как прокси
В конечном итоге поток управления выглядит примерно так:
Смысл всего вышеперечисленного в том, чтобы помочь вам получить некоторое представление о том, почему вы можете видеть часть кода, который вы делаете, а также почему вам нужно структурировать свой код именно так.