Статьи

WP REST API: настройка и использование базовой аутентификации

Во вводной части этой серии мы быстро ознакомились с архитектурой REST и тем, как она может помочь нам создавать лучшие приложения. Затем мы изучили историю API-интерфейсов REST в WordPress и познакомились с последним дополнением: плагином WP REST API. Мы настроили базовую рабочую среду для тестирования с помощью плагина, которая включала в себя установку плагина и HTTP-клиента для отправки запросов или просмотра ответа сервера.

В текущей части серии мы настроим базовый протокол аутентификации на сервере для отправки аутентифицированных запросов для выполнения различных задач через REST API.

Чтобы быть конкретным, в этой части мы будем:

  • посмотрите на различные методы аутентификации, доступные при использовании плагина REST API
  • настроить базовую аутентификацию на сервере
  • отправить аутентифицированный запрос с помощью Почтальона
  • отправить аутентифицированный запрос с использованием JavaScript-фреймворка
  • отправить аутентифицированный запрос с помощью командной строки
  • отправить аутентифицированный запрос с помощью WP HTTP API

Но давайте сначала посмотрим на саму аутентификацию.

В своем самом основном определении аутентификация — это процесс определения личности человека.

Согласно Вебопедии :

Процесс идентификации личности, как правило, основан на имени пользователя и пароле. В системах безопасности аутентификация отличается от авторизации, которая представляет собой процесс предоставления пользователям доступа к системным объектам на основе их личности. Аутентификация просто гарантирует, что индивид является тем, кем он или она претендует, но ничего не говорит о правах доступа индивида.

Говоря о WP REST API, пользователь с достаточными привилегиями может выполнять различные задачи CRUD, такие как создание сообщения, получение всех пользователей сайта или отзыв прав пользователя. Но для всех этих действий нужно доказать свою личность серверу, и именно здесь аутентификация играет свою роль.

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

WP REST API предоставляет три варианта аутентификации, каждый из которых предназначен для определенной цели. Эти варианты:

  • базовая аутентификация
  • OAuth-аутентификация
  • проверка подлинности cookie

Прямо сейчас, родной способ аутентификации в WordPress — это аутентификация с помощью куки. Вот как WordPress определяет личность пользователя и какие действия он может выполнять. Чтобы использовать два других метода аутентификации, перечисленных выше, с WP REST API, нам нужно установить соответствующие плагины, предоставленные командой API REST API, доступной на GitHub. Надеемся, что эти два метода также будут включены в ядро ​​WordPress с помощью самого плагина REST API.

Базовая аутентификация — это самый базовый тип аутентификации HTTP, при котором учетные данные для входа отправляются вместе с заголовками запроса.

При базовой аутентификации клиент запрашивает URL-адрес, который требует аутентификации. Сервер запрашивает у клиента (или агента пользователя) аутентификацию, отправляя код 401-Not Authorized . В свою очередь, клиент отправляет обратно тот же запрос, но с учетными данными для входа в виде строки в кодировке base64 в формате username:password . Эта строка отправляется в поле заголовка Authorization следующим образом:

1
Authorization: Basic {base64_encode(username:password)}

Таким образом, если имя пользователя — tutsplus а пароль — 123456 , следующее поле заголовка будет отправлено с запросом:

1
Authorization: Basic dHV0c3BsdXM6MTIzNDU2

Поскольку закодированная в base64 строка может быть легко декодирована, этот метод крайне небезопасен для использования в открытой сети. Следовательно, этот метод должен использоваться только для целей отладки и разработки, когда соединение между сервером и клиентом является доверенным.

Как упоминалось выше, плагин доступен на GitHub от команды WP REST API. Так что все, что нам нужно сделать, это клонировать его в наш каталог plugins и активировать его.

Перейдите в каталог /wp-content/plugins/ и клонируйте плагин, для которого вам могут потребоваться права sudo для запуска команды. Для этого выполните следующее:

1
$ sudo git clone https://github.com/WP-API/Basic-Auth.git

Терминал запросит ваш пароль. Введите свой пароль и позвольте хранилищу клонироваться в каталог.

После клонирования плагина активируйте его, зайдя в WP Admin. Базовый метод аутентификации HTTP теперь можно использовать с плагином REST API.

Большинство HTTP-клиентов поддерживают отправку запроса с использованием базового метода аутентификации, как и Postman for Chrome. Чтобы отправить аутентифицированный запрос, перейдите на вкладку Авторизация под адресной строкой:

Вкладка авторизации

Теперь выберите Basic Auth из выпадающего меню. Вам будет предложено ввести имя пользователя и пароль. После ввода учетных данных нажмите кнопку « Запрос на обновление» .

Базовая аутентификация

После обновления опции аутентификации вы увидите изменение на вкладке Заголовки , и теперь оно включает поле заголовка, содержащее зашифрованную строку имени пользователя и пароля:

Заголовок авторизации

Это все о том, как мы настроили базовую аутентификацию с почтальоном. Теперь вы можете отправить тестовый запрос, например, удалить сообщение, которое требует аутентификации:

1
DELETE http://dev-server/wp-json/wp/v2/posts/52

Где dev-server — это путь к вашему серверу разработки.

Если все пойдет хорошо, сервер вернет код состояния 200 OK , указывающий, что сообщение с идентификатором 52 было удалено:

Сообщение создано

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

Мы можем использовать командную строку для отправки аутентифицированных запросов, используя этот метод. Рассмотрим следующий эквивалент curl вышеупомянутого запроса:

1
curl —request DELETE -I —user admin:password http://dev-server/wp-json/wp/v2/posts/52

Следующий ответ будет отправлен сервером, указывая, что все в порядке:

01
02
03
04
05
06
07
08
09
10
11
12
13
HTTP/1.1 200 OK
Date: Fri, 28 Aug 2015 20:02:43 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.6.12
X-Powered-By: PHP/5.6.12
Set-Cookie: PHPSESSID=k0rg6mcbsie7ufvoav219lqre0;
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Content-Type-Options: nosniff
Link: <http://localserver/wordpress-api/demo-post-28/>;
Allow: GET, POST, PUT, PATCH, DELETE
Transfer-Encoding: chunked
Content-Type: application/json;

Опция --request указывает используемый метод запроса, который в нашем случае — DELETE . Вы также можете использовать -X в качестве альтернативы опции --request .

Опция -I выбирает только заголовки HTTP, отправленные сервером. Альтернативой -I является опция --head .

Если вы используете клиентскую среду JavaScript, такую ​​как jQuery, для удаленного взаимодействия с сайтом WordPress с включенным WP API, вы можете отправлять заголовки авторизации в запросе AJAX. Рассмотрим следующий запрос DELETE отправленный с помощью jQuery.ajax() :

01
02
03
04
05
06
07
08
09
10
11
12
$.ajax({
    url: ‘http://dev-server/wp-json/wp/v2/posts/52’,
    method: ‘DELETE’,
    crossDomain: true,
    beforeSend: function ( xhr ) {
        xhr.setRequestHeader( ‘Authorization’, ‘Basic ‘ + Base64.encode( ‘username:password’ ) );
    },
    success: function( data, txtStatus, xhr ) {
        console.log( data );
        console.log( xhr.status );
    }
});

Где Base64 — это объект, используемый для кодирования и декодирования строки base64. Это определяется следующим образом перед jQuery.ajax() метода jQuery.ajax() :

1
var Base64={_keyStr:»ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=»,encode:function(e){var t=»»;var n,r,i,s,o,u,a;var f=0;e=Base64._utf8_encode(e);while(f<e.length){n=e.charCodeAt(f++);r=e.charCodeAt(f++);i=e.charCodeAt(f++);s=n>>2;o=(n&3)<<4|r>>4;u=(r&15)<<2|i>>6;a=i&63;if(isNaN(r)){u=a=64}else if(isNaN(i)){a=64}t=t+this._keyStr.charAt(s)+this._keyStr.charAt(o)+this._keyStr.charAt(u)+this._keyStr.charAt(a)}return t},decode:function(e){var t=»»;var n,r,i;var s,o,u,a;var f=0;e=e.replace(/[^A-Za-z0-9\+\/\=]/g,»»);while(f<e.length){s=this._keyStr.indexOf(e.charAt(f++));o=this._keyStr.indexOf(e.charAt(f++));u=this._keyStr.indexOf(e.charAt(f++));a=this._keyStr.indexOf(e.charAt(f++));n=s<<2|o>>4;r=(o&15)<<4|u>>2;i=(u&3)<<6|a;t=t+String.fromCharCode(n);if(u!=64){t=t+String.fromCharCode(r)}if(a!=64){t=t+String.fromCharCode(i)}}t=Base64._utf8_decode(t);return t},_utf8_encode:function(e){e=e.replace(/\r\n/g,»\n»);var t=»»;for(var n=0;n<e.length;n++){var r=e.charCodeAt(n);if(r

Я нашел его в StackOverflow, и это кросс-браузерный способ кодирования и декодирования строки base64 в JavaScript.

В приведенном выше запросе мы устанавливаем заголовок Authorization с помощью setRequestHeader() объекта xhr переданного в качестве аргумента beforeSend() .

В дополнение к вышеприведенному запросу заголовки Access-Control-Allow-Headers должны разрешить поле Authorization на сервере. Это можно включить, добавив следующую строку кода в ваш файл WordPress .htaccess:

1
Header always set Access-Control-Allow-Headers Authorization Header always set

Вышеупомянутый запрос, когда он будет выполнен, отобразит ответ в консоли вашего браузера, как показано на рисунке ниже:

Ответ сервера

Код ответа 200 статусов, возвращаемый сервером, показывает, что сообщение с идентификатором 52 успешно удалено.

Если вы взаимодействуете удаленно с другим сайтом WordPress из вашей установки WordPress, наиболее подходящим способом отправки HTTP-запросов является WP HTTP API.

Рассмотрим следующий код, который отправляет запрос DELETE в другую установку WordPress с включенным WP REST API и базовой аутентификацией:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
$wp_request_headers = array(
    ‘Authorization’ => ‘Basic ‘ .
);
 
$wp_request_url = ‘http://localserver/wordpress-api/wp-json/wp/v2/posts/52’;
 
$wp_delete_post_response = wp_remote_request(
    $wp_request_url,
    array(
        ‘method’ => ‘DELETE’,
        ‘headers’ => $wp_request_headers
    )
);
 
echo wp_remote_retrieve_response_code( $wp_delete_post_response ) .

Здесь мы использовали wp_remote_request() которая принимает два аргумента:

  • $url : URL запроса
  • $args : массив дополнительных передаваемых аргументов

Метод $method определенный в массиве $args равен DELETE , и его всегда следует писать в верхнем регистре. Массив $headers принимает пары значений ключей всех полей заголовка, которые будут переданы с запросом. Мы передали ключ Authorization со значением имени пользователя и пароля в кодировке base64.

Ответ будет сохранен в переменной $wp_delete_post_response , которую мы можем использовать с wp_remote_retrieve_response_code() и wp_remote_retrieve_response_message() . Эти две функции являются вспомогательными функциями в API HTTP HTTP и извлекают код состояния и сообщение о состоянии из ответа соответственно.

Если сообщение было успешно удалено по вышеуказанному запросу, будет выведен следующий текст:

1
200 OK

Это все о базовом методе аутентификации, поддерживаемом WP REST API. Мы будем использовать тот же метод аутентификации в наших будущих частях для извлечения, создания или изменения данных из-за его простоты, если не указано иное.

В текущей части серии мы подробно рассмотрели базовый метод HTTP-аутентификации, поддерживаемый WP REST API. Однако его не следует использовать в реальных производственных средах, поскольку закодированная в base64 строка может быть легко декодирована и ваши учетные данные могут попасть в чужие руки.

Успешно настроив и протестировав базовый метод аутентификации HTTP, мы готовы сделать еще один шаг и установить более сложный способ аутентификации — метод OAuth 1.0a. Мы сделаем это в самой следующей части серии, так что следите за обновлениями!