Настройка аутентификации WordPress через внешний API

31 мая 2017 г., 12:39:54
Просмотры: 20.9K
Голосов: 9

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

Мне предоставили конечную точку (www.example-api.com/token) и учетные данные для входа (email и пароль), которые возвращают токен (и другие детали) в качестве ответа.

Я читал про OAuth, и большинство ресурсов, которые я нахожу, описывают обратную ситуацию (вход на не-WordPress сайт с использованием учетных данных WordPress). У меня нет доступа к другому сайту, и я вижу, что там нужна настройка, так что, стоит ли мне отказаться от этого варианта?

Я натолкнулся на возможность переопределения wp_authenticate через пользовательский плагин, который я уже настроил, но я в замешательстве относительно того, что и КАК именно нужно сделать.

Есть ли какие-либо рекомендации или подсказки по этому поводу?

2
Комментарии

В настоящее время я не вижу никакого осуществимого способа сделать это без двери (интерфейса) с сайта, не работающего на WordPress. Иначе: где вам нужно подтверждать, что учетные данные, отправленные пользователями с не-WP сайта, действительно правильные и соответствуют конкретному пользователю? Надеюсь, вы понимаете!

nyedidikeke nyedidikeke
31 мая 2017 г. 14:17:35

Думаю, я недостаточно четко выразился – у меня был доступ к конечной точке (endpoint), а также тестовые данные с email-адресами и паролями аккаунтов, которые мне нужны. Впрочем, я уже сделал это, сейчас опубликую. Спасибо за помощь! :)

Suika Suika
5 июн. 2017 г. 12:58:54
Все ответы на вопрос 1
9
12

Обновление: Создал пост в блоге, чтобы объяснить это подробнее :)


Мне удалось реализовать это с помощью фильтра WP authenticate внутри нового плагина; большая часть основана на этом руководстве от Бена Лобо. Основные моменты плагина:

  • Создать функцию API-вызова с помощью cURL (если не знакомы, можно получить пример кода из Postman при тестировании).
  • Добавить фильтр, проверяющий, что ответ от API подтверждает существование пользователя и его доступ (в моем случае — на основе роли).
  • В том же фильтре проверить, есть ли у пользователя аккаунт на сайте WP — если нет, создать его через wp_insert_user. Для ясности: я использовал email и пароль, проверенные API, потому что WP требует зарегистрированного пользователя в своей базе.
  • Если пользователь уже есть в базе WP, убедиться, что его данные актуальны, используя wp_update_user. Это нужно для случаев, например, когда пользователь изменил свои данные на основном (не-WP) сайте.
  • Опционально добавить страницу настроек плагина. В моем случае я создал поле для URL запроса, следуя этому руководству от Бхарата Парика.
6 июн. 2017 г. 05:32:41
Комментарии

Итак, вы реализовали своего рода SSO, что действительно единственный правильный подход. Но фраза "если пользователь не существует, создайте учетную запись" звучит очень неправильно. Любая атака методом грубой силы в некотором масштабе может положить ваш WordPress

Mark Kaplun Mark Kaplun
6 июн. 2017 г. 05:49:52

Можете объяснить подробнее? У меня сложилось впечатление, что мне нужно создавать локального пользователя WordPress, поскольку в руководстве, которому я следовал (первая ссылка), явно сказано: "WordPress требует, чтобы реальный пользователь (пользователь WordPress) присутствовал в базе данных WordPress для выполнения операций с этим пользователем."

Я создаю нового пользователя только если ответ API указывает на это, и регистрирую их, используя их email и пароль из API.

Suika Suika
6 июн. 2017 г. 06:00:32

Возможно, это просто неточность в вашем описании или мое недопонимание, но звучит так, будто вы создаете пользователя при каждом запросе "проверки".

Mark Kaplun Mark Kaplun
6 июн. 2017 г. 07:43:09

О, кажется, я понял... вы аутентифицируете пользователей WordPress через другой сайт. В таком случае ваша логика верна

Mark Kaplun Mark Kaplun
6 июн. 2017 г. 07:46:24

Понял. Да, вероятно, дело в формулировке. Я отредактирую, чтобы сделать понятнее. Спасибо!

Suika Suika
6 июн. 2017 г. 09:06:50

Ссылка на блог возвращает ошибку 404

M.Babcock M.Babcock
25 янв. 2019 г. 00:59:11

Исправил ссылку на блог! :)

Suika Suika
14 мар. 2019 г. 09:08:59

Спасибо! Я думаю, возможно, использовать этот подход. Как вы обрабатываете ситуацию, когда пользователь меняет пароль в не-WP приложении? Вы просто используете WP REST API для обновления?

Kevin Amorim Kevin Amorim
9 дек. 2020 г. 11:53:00

Да, именно так я это реализовал, поскольку авторизация на не-WP сайте — единственное место, где они могут обновить пароль в любом случае. Удачи! :)

Suika Suika
10 дек. 2020 г. 16:08:25
Показать остальные 4 комментариев