Що означає використовувати WordPress як проксі?

Якщо ви працювали з WordPress протягом певного періоду часу, особливо коли справа доходить до використання певного типу функціональності Ajax, то ви, ймовірно, колись чули фразу «використовуйте WordPress як проксі».

І навіть якщо у вас немає шансів, що ви справді це зробили, досить високі.

Хоча я думаю, що з часом ми побачимо, що REST API замінить традиційні способи використання Ajax, але це, ймовірно, інша історія іншим разом.

Отже, що означає використовувати WordPress як проксі, коли ви працюєте із запитами Ajax? Для цього потрібно трохи зрозуміти міжсайтові запити, як працює маршрутизація запиту через WordPress, а потім розібрати відповідь.

Використовуйте WordPress як проксі

Це трохи довгий пост, чи не так? Натомість я спробую розбити це коротше, щоб ви могли прочитати його та повернутися до роботи.

Як проксі

Спочатку візьмемо визначення проксі :

повноваження представляти когось іншого, особливо під час голосування

Якщо ви клацнете посилання вище, ви помітите, що є кілька інших визначень, але жодне з них насправді не є достатнім. Натомість я люблю думати про них трохи абстрактніше, принаймні, що стосується програмного забезпечення.

Для цілей цієї публікації припустимо, що WordPress є проксі-сервером для запиту, що означає, що він відповідає за виконання функції посередника між початком запиту та відповіддю на нього.

Коротко,

WordPress виконує роль проксі-сервера, направляючи запит до іншої служби та фіксуючи її відповідь.

Можливо, ви чули щось подібне, можливо, ні. Незважаючи на це, ось як це може виглядати на високому рівні:

Тепер, коли вам потрібно зробити асинхронний запит (або запит Ajax, як я буду використовувати в решті цієї публікації), у вас є один із двох варіантів:

1. зробити запит на сторінку, яка існує в WordPress,
2. зробити запит до сторінки, яка існує в іншому домені.

Якщо ви робите запити до сторінок, які існують у вашому додатку (читайте: у WordPress), у вас не буде проблем.

Про безпеку запитів

Але робити запити Ajax за межами власного домену заборонено. Це тому, що він призначений для захисту XSS і CSRF.

Коротше кажучи, кожен із них відповідно стосується наступного:

XSS-атаки відбуваються, коли зловмисник використовує веб-програму для надсилання шкідливого коду, як правило, у формі сценарію сторони браузера, іншому кінцевому користувачеві

і:

Підробка міжсайтового запиту (CSRF) — це атака, яка змушує кінцевого користувача виконувати небажані дії у веб-програмі, у якій він наразі пройшов автентифікацію.

Коротше кажучи, ось чому нам потрібно використовувати WordPress як проксі. Природно, що виникає питання, як?

Використання WordPress як проксі

Для цього вам знадобиться кілька речей:

1.  сторінка, на яку запитує запит Ajax,
2. функція для перехоплення запиту ajax і надсилання його на правильну URL-адресу,
3. спосіб для сторони сервера аналізувати відповідь,
4. функція для повернення даних до вихідної функції 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 як проксі

Зрештою, потік керування виглядає приблизно так:

Суть усього вищесказаного полягає в тому, щоб допомогти надати трохи фону щодо того, чому ви можете бачити частину коду, який ви робите, а також чому вам потрібно структурувати свій код саме так.