Единая регистрация и многое другое с помощью OAuth2 в XenForo 2.3

  • Меценат
1699501779311.png

Мы приближаемся к завершению серии "А вы видели...?" для XenForo 2.3. Хотя это может показаться горько-сладким моментом, мы намеренно приберегли одно из самых интересных открытий напоследок. В ближайшие недели мы, возможно, рассмотрим еще несколько различных изменений и улучшений, а также подготовим более подробный обзор, ориентированный на разработчиков. Однако главная цель разработчиков - запустить XenForo 2.3 на сайте XenForo.com к концу ноября. После достижения этой цели мы с радостью поделимся с вами еще несколькими сюрпризами, которые будут включать в себя обзор последних улучшений в Resource Manager, Enhanced Search, и Media Gallery 2.3.

Но вернемся к сегодняшнему дню, и это не только захватывающее открытие, но и сигнал к реализации нашего . Ваша установка XenForo сможет выступать в качестве сервера OAuth2, что открывает целый ряд дополнительных возможностей:

  • Единая авторизация между вашим форумом и другой установкой XenForo
  • Единая авторизация между вашим форумом и другим программным обеспечением
  • Создание другого фронт-энда для вашего форума, например, одностраничного приложения
  • Создание собственного приложения для смартфонов для вашего форума
  • Интеграция между вашим форумом и другим приложением
  • Доступ к XenForo REST API от имени конкретного пользователя с маркером OAuth
Как обычно, давайте рассмотрим, как это настроить в XenForo 2.3. В следующем примере мы настроим OAuth2-клиент на первичном экземпляре XenForo и будем использовать вторичный экземпляр XenForo для использования первичного экземпляра в качестве поставщика подключенных учетных записей.

Вы можете добавить столько OAuth2-клиентов, сколько вам необходимо, и это можно сделать из панели управления администратора в разделе Setup > OAuth2 clients (где перечислены все созданные вами клиенты), нажав кнопку "Add OAuth2 client".

А вот так выглядит заполненная страница:

1699500811357.png

Большинство из них не требует пояснений. Заголовок, описание, URL домашней страницы и URL изображения используются для брендирования любой страницы авторизации OAuth. Рассмотрим подробнее некоторые другие параметры на этой странице.

Тип клиента​

Разница между типами клиентов "Публичный" и "Конфиденциальный" может быть не сразу очевидна, но она очень важна. Для подавляющего большинства интеграций OAuth, с которыми вы, возможно, сталкивались в прошлом, скорее всего, более привычен вариант по умолчанию - тип "Конфиденциальный".

Для большинства приложений тип "Конфиденциальный" вполне подходит. Это означает, что вы можете сохранить конфиденциальность клиентского секрета - другими словами, клиентский секрет нигде не хранится и не раскрывается клиентом. Это подходит для учетной записи, подключенной к XenForo.

Для ситуаций, когда хранить секрет в клиентском приложении небезопасно (например, в JavaScript, одностраничных приложениях или нативных приложениях), следует выбрать тип клиента 'Public'. При использовании типа 'Public' применяется поток авторизации . Вместо того чтобы передавать секрет, создается случайная строка. Эта случайная строка служит надежным способом подтверждения вашей личности в процессе авторизации и обмена токенами.

Следует отметить, что PKCE требуется для публичных клиентов и рекомендуется для конфиденциальных. Более глубокое изучение PKCE выходит за рамки данной статьи, но будьте уверены, что до выхода XenForo 2.3 все будет описано в руководстве и/или документации разработчика.

Авторизация / Токен / Revocation endpoints​

Это просто конечные точки, с которыми необходимо взаимодействовать для авторизации, получения маркера и отзыва маркеров в соответствии со спецификацией OAuth 2.0.

URI перенаправления​

Здесь можно добавить один или несколько URI перенаправления. Это утвержденные URI перенаправления, которые может использовать вторичный экземпляр. Иногда может потребоваться несколько URI перенаправления для поддержки различных доменов или различных конечных точек, которые могут быть вызваны в рамках процесса. В данном примере, поскольку мы будем осуществлять связь со второго форума XenForo, в качестве URI перенаправления достаточно использовать его connected_account.php.


После создания клиента вы сможете просмотреть свои учетные данные:

1699501457135.png

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

1699501497433.png

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

Но на самом деле вы хотите увидеть процесс авторизации, не так ли?

На странице входа, регистрации или Account > Connected accounts, как только вы нажмете кнопку, соответствующую вашему новому провайдеру подключенного аккаунта XenForo, вы будете перенаправлены на страницу авторизации:

1699501591993.png

При нажатии кнопки Авторизация будут выполнены обычные действия по аутентификации с использованием OAuth и перенаправлению вас обратно:

1699501647721.png

Если вы одобрили какие-либо приложения для доступа к вашей учетной записи XenForo, то их список можно увидеть в разделе Учетная запись > Приложения:

1699501709251.png

Хотя это и интересно само по себе, это всего лишь один из многих вариантов использования, которые откроет наша реализация OAuth. На этом мы заканчиваем эту неделю. На следующей неделе мы посвятим целую статью "Видели ли вы...?" тому, что нового для разработчиков появилось в XenForo 2.3. Это позволит нам более детально рассмотреть некоторые небольшие изменения, ориентированные на разработчиков, в том числе более подробно остановиться на некоторых более продвинутых частях OAuth, таких как PKCE, аутентификация по REST API и маркеры обновления.

Если разработчики хотят, чтобы мы более подробно рассказали о чем-то конкретном, о чем мы могли упомянуть в последние несколько недель, пожалуйста, дайте нам знать.
 
А задумка интересна. Я так понимаю, на любой платформе при поддержки OAuth, а её как правило имеют большинство соц. сетей, то получается можно будет связать общую учётку с основным форумом. Если я правильно понимаю, например мы ставим тот же WordPress, то можно будет без лишних костылей связать общую регистрацию между им и форумом. И другие платформы не исключение. Но мудрить мосты такие, очень пагубно сказываются на SEO, но с тем условием, если это использовать на одном домене, а если у тебя разные домены и подача ресурсов, то задумка имеет место быть. Мне подобная фишка вряд ли пригодится, но реализация интересная.
 
Последнее редактирование:
О боже, наконец-то я смогу выкинуть свой велосипед, который делает именно OAuth2 сервер на Ксене.
 
Интересно будет наверное тем, у кого есть еще один сайт и нужна общая авторизация. Для меня пока бесполезная тема :( Ну а так, в целом полезная тема. :)
 
MrFallen, не только для этих целей OAuth2 полезен. Еще для сторонних скриптов, которые реализуют свою регистрацию-авторизацию, но так же, помимо этого способа, умеют в сторонних провайдеров. Та же MediaWiki, например, или что-то более экзотическое, для чего дополнения под Ксен нет.
 
Единая авторизация это конечно хорошо. НО! Можно ли будет на двух разных форумах(форумы с разными адресами) иметь одну и ту же базу юзеров?
 
ФАКЕР, формально да, просто это технически будет работать немного иначе, и у юзеров будут разные user_id между форумами.
 
Имеем Яндекс ID, Google, VK и множество других ID-авторизаций в разных странах. Но нет внедряем Xen ID для того, чтобы... А собственно для чего? Для связи одного форума с другим? Или для общего входа через инсту или ВК, но ведь это все имеется. В сегодняшних реалиях, когда все против всех не уместное решение. Доступ приложений к форуму? Ээээ, а как же webapp и разрешение доступа форума к вашим гуглам, яндексам и прочее и прочее (выбрать по месту проживания). Есть API, как с этими доступами быть. Странное и непонятное решение.
 
Имеем Яндекс ID, Google, VK и множество других ID-авторизаций в разных странах. Но нет внедряем Xen ID для того, чтобы... А собственно для чего? Для связи одного форума с другим? Или для общего входа через инсту или ВК, но ведь это все имеется. В сегодняшних реалиях, когда все против всех не уместное решение. Доступ приложений к форуму? Ээээ, а как же webapp и разрешение доступа форума к вашим гуглам, яндексам и прочее и прочее (выбрать по месту проживания). Есть API, как с этими доступами быть. Странное и непонятное решение.
Оч странный вопрос. Тот же вход через форум на торговых серверах, в лаунчерах и других приложениях, для этого все и делается
И форум из других OpenId провайдеров может вытащить только вашу почту, но он не может что либо делать с вашим аккаунтом
Вы вообще смешали все в одну кучу и сами же запутались
 
Я себе колхозил OAuth Server (по сути то, что и запилили разработчики в 2.3), чтобы можно было писать отдельно сайты, использующие уже имеющуюся базу пользователей и регистрацию, не переизобретая с нуля регистрацию/авторизацию. Это тупо проще и легче в поддержке.
Я в своей системе храню только user_id пользователя форума и непосредственно те данные, которые генерирует мой ресурс, а пользователю не нужно придумывать новую пару логин-пароль или вводить их повторно, если у него уже есть авторизация на форуме. Он просто жмёт кнопку "Войти через xenForo.info", подтверждает один раз выдачу прав моему ресурсу, и всё. В этом же и суть внешних провайдеров в самом движке, только тут может понадобиться ещё какие-то поля заполнить.
 
Осталось 2 проекта открыть, для полного счастья. Но пока возможности нет.
 
А что происходит? Прошло два года с момента анонса крупного обновления и до сих пор даже беты нет. Никто не знает? Вроде немало денег получают с лицензий и подписок
 
А что происходит? Прошло два года с момента анонса крупного обновления и до сих пор даже беты нет. Никто не знает? Вроде немало денег получают с лицензий и подписок
Ничего не происходит. Так было с самого создания движка и так будет. Вот и весь ответ
 
Ничего не происходит. Так было с самого создания движка и так будет. Вот и весь ответ
Пока заинтересовался - зашел на оф и охренел: там уже во всю в открытую недовольствуются и говорятся то же самое - мол, баги не правят годами и их все больше, а обновлений все меньше... Тускло
 
Современный облачный хостинг провайдер | Aéza
Назад
Сверху Снизу