4.3: Авторизация с других сайтов через OAuth

Лучший способ конвертировать гостей в пользователей - сделать процесс присоединения максимально простым. Invision Community всегда использовал способы авторизации через социальные сети для Facebook, Google, LinkedIn, Twitter, Microsoft. Что позволяет гостям пройти регистрацию за несколько секунд с помощью сервиса, к которому они уже присоединились. Эти способы используют простую ссылку и некоторые данные, но в 4.3 появился новый стандарт.

OAuth

Вы, возможно не знали этого, но вы, вероятно, уже знакомы с OAuth. Если вы позволили пользователям вашего сообщества войти в систему со своими аккаунтами Facebook, Twitter, Google, LinkedIn или Microsoft, возможно, вы заметили, что процесс настройки каждого из этих способов очень схож. Это связано с тем, что все они используют протокол OAuth.

В Invision Community 4.3 добавлено несколько интересных новых функций:

• В дополнение ко все уже существующим социальным сетям (которые сохраняют статус быстрой настройки), были так же добавлены Instagram и Wordpress. Пользователи вашего сообщества теперь смогут авторизовать с помощью аккаунта в Instagram и любым сайтом на Wordpress, которым вы управляете (для Wordpress необходимо будет установить плагин для активации OAuth возможностей).
• Помимо этих "простых в настройках" параметров, так же добавлена возможность, разрешающая пользователям вашего сайта авторизоваться с помощью любого провайдера OAuth 2.0. То есть, например, если ваше сообщество работает там, где есть популярные социальные сети, использующие протокол OAuth, вы можете настроить авторизацию через них. Хотя настройка авторизации OAuth немного сложнее, она не требует какого-либо знаний программирования - вам просто нужно будет узнать еще несколько деталей от провайдера (пример приведен ниже).
• Сообщество Invision Community теперь само служит сервером OAuth 2.0, поэтому вы можете настроить другие сайты для авторизации в них, используя учетные данные вашего сообщества. Это работает в сочетании с REST API, позволяя вам выполнять API вызовы как аутентифицированному пользователю, что будет возвращать информацию, к которой у пользователя есть доступ.
• Благодаря возможности Invision Community выступать как сервером OAuth, так и клиентом, она является стандартной интеграцией нескольких сообществ Invision Community, заменяя при этом функции IPS Connect.
• Так же сделаны некоторые правки в процесс аворизации, регистрации и управлении аккаунтом, особенно полезно для сообществ, которые в значительной степени полагаются на нестандартные методы авторизации в систему (подробнее см. ниже)

Настройка пользовательского провайдера OAuth

В этом примере мы рассмотрим интеграцию с vk.com. Хотя Invision Community не предоставляет интеграцию с vk.com как одну из предустановленных, она основана на OAuth 2.0, поэтому мы можем использовать новую функциональность в Invision Community 4.3 для её настройки.

В прошлых версиях, список методов авторизации в админцентре содержал всех провайдеров с кнопкой включить/отключить. Теперь вы можете добавлять столько провайдеров, сколько захотите:

Когда вы нажимаете кнопку "Создать", вы увидите список со всеми различными провайдерами, которые по умолчанию поддерживает Invision Community. Поскольку Вконтакте не поддерживается изначально, но поддерживает OAuth 2.0, необходимо выбрать пункт "Other OAuth 2.0":

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

На скриншоте мы создали приложение в центре разработчика vk.com, и копируем свои учетные данные в форму:

Затем нужно найти конечные точки из документации vk.com и указать их тоже.

Далее необходимо найти конечную точку, с помощью которой можно получить доступ к информации пользователя. Единственной обязательной информацией является идентификатор, но вы также можете предоставить параметры для доступа к отображаемому имени, адресу электронной почты и фотографии профиля. Если отображаемое имя/e-mail адрес недоступны/не предоставлены, пользователю будет предложено указать эти данные при первой авторизации. API vk.com не предоставляет доступ к e-mail адресу, мы можем использовать настоящее имя в качестве отображаемого в сообществе, а так же API предоставляет доступ к фото:

Наконец, укажите логотип и цвет кнопки авторизации и некоторые окончательные настройки:

Теперь авторизация через vk.com настроена. В сообществе появится соответствующая кнопка. Мы не указывали спопосба для получения e-mail адреса, поэтому при первой авторизации, пользователю будет предложено предоставить эти данные, и будет использовано настоящее имя и фотография профиля из vk.com:

Использование Invision Community в качестве сервера OAuth

Вы также можете настроить Community Invision как сервер OAuth. Это может быть полезно в двух случаях:

• Если вы хотите объединить два сообщества вместе или интегрироваться с чем-то другим, что поддерживает добавление пользовательских клиентов OAuth.
• Если вы разработчик и хотите использовать REST API, используя OAuth для аутентификации, вместо API-ключа. Вы можете либо делать запросы в качестве аутентифицированного пользователя (путем получения токена доступа), либо с помощью Client Credentials.

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

Вы должны настроить клиент в админцентре

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

Процесс входа в систему - это стандартный поток OAuth, и пользователи могут просматривать разрешения в настройках учетной записи:

REST API имеет новые и обновлённые конечные точки, чтобы знать пользователя, прошедшего авторизацию:

Другие дополнения системы авторизации

• Пользователи теперь могут выбирать, хотят ли они сменить локальное отображаемое имя или e-mail адрес, если эти данные изменены внешним провайдером авторизации (или администратор может выбрать это поведение). Если с этим возникла проблема (например, пользователь хочет сменить e-mail на уже занятый), пользователь будет знать об этом.
• Теперь вы можете управлять управлять регистрацией непосредственно через провайдер. 
• Стандартный обработчик авторизации может быть отключён, если вы полностью полагаетесь на альтернативный метод. Для этого:
  • Во всех областях, где пользователю предлагается повторно ввести свой пароль (некоторые области настроек учетной записи), разрешена повторная аутентификация с помощью любого способа авторизации.

  • Вы можете отключить регистрацию, но оставить создание учётных записей с помощью других способов авторизации, или перенаправить пользователей на внешний адрес для регистрации.

  • Вы также можете отключить или перенаправить на внешний URL-адрес для смены e-mail адреса / пароля или инструмента восстановления пароля.

• Вы теперь можете создать несколько экземпляров способов авторизации внешняя база данны MySQL и LDAP, которые также имели некоторые незначительные изменения:

  • Способ Внешняя MySQL база данных теперь имеет PHP функцию password_hash() в качестве доступной опции для типа шифрования пароля, а определение пользовательского метода шифрования теперь намного проще, полностью выполняется в админцентре без необходимости изменять PHP файлы.

  • Теперь вы можете выбрать, будут ли изменения в локальных данных (имя пользователя, e-mail адрес, пароль) синхронизироваться обратно во внешнюю базу данных / базу данных LDAP.

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

  • Вы можете определить URL-адрес для восстановления пароля для внешней базы данных, к которой пользователь будет перенаправлен, если он попытается использовать этот инструмент.