Оглавление
На одном проекте нам понадобилось парсить данные сразу из четырех социальных сетей, а также собирать их в одном месте. Мы решили поделиться столь ценным опытом и рассказать о главных принципах работы с социальными сетями на примере Facebook, Instagram и Twitter.
Регистрация приложения
Работа с социальными сетями начинается с создания приложения. Демонстрируем на примере Твиттера, но настройка на других платформах производится аналогично. Итак, нам сюда.
Для создания приложения нужно заполнить следующие поля: имя, адрес сайта и callback url. О том, что такое callback url мы расскажем чуть ниже.
Как видите, в адресах ссылок нельзя использовать localhost — вместо него вводим 127.0.0.1:3000.
Callback url — это адрес, на который будут отправлены данные пользователя после авторизации.
Далее нам нужны ключи приложения.
Копируем API Key И API Secret. А теперь идем настраивать Rails.
Типы авторизации в API
Для того чтобы выполнить запрос в социальной сети, нужна авторизация. И тут у нас два пути:
- Авторизация от приложения
- Авторизация от пользователя
То есть тип авторизации определяет реквестера запросов. Давайте разбираться. Для авторизации от приложения вам достаточно пары API Key и API Secret, полученной при регистрации. В этом случае у вас будет доступ ко всем публичным данным пользователей. Но лимит запросов окажется ограниченным.
Авторизация от пользователя позволит получить доступ ко всем данным, на которые он дал разрешение. После авторизации у вас будет еще пара токенов Key и Secret. Их нужно сохранить для последующего использования.
Примечание: Некоторые соцсети, например, Facebook возвращают лишь одно значение.
Зачем нужен Callback URL в настройках приложения
В случае успешной авторизации социальная сеть должна отправить нам данные пользователя. Для этого ей нужен какой-то адрес. На самом деле, его отправляет наше приложение на этапе авторизации. В настройках мы указываем адрес для безопасности, а социальная сеть проверяет совпадение и выдает ошибку в случае несоответствия.
Примечание: Возможность использовать localhost присутствует не всегда. Но вы можете юзать локальный IP адрес. Мы поступили именно так.
Omniauth and Devise — авторизация пользователей через социальные сети
На стороне Rails все достаточно просто, если знать о паре подводных камней. Но до них мы еще дойдем, а пока давайте по порядку
Гемы
gem ‘omniauth’
gem ‘omniauth-facebook’
gem ‘omniauth-twitter’
gem ‘omniauth-linkedin’
gem ‘omniauth-instagram’
gem ‘devise’
Ключи и инициализация
Все ключи хорошо бы хранить в одном месте. В Rails для этого задумывался файл config/secrets.yml, но он не поддерживает вложенность из коробки. Поэтому придется работать по старинке.
Создаем файл config/omniauth_keys.yml. Не забываем добавить его в .gitignor!
Примечание: перед вами не реальные ключи и работать они не будут. Просто хотелось для наглядности оставить ключи, похожие на оригинал. Дело в том, что у каждой социальной сети они обзываются по-своему. Мы же привели названия к одному формату.
Создаем initializer config/initializers/omniauth.rb
Как видите, для Фейсбука был использован параметр scope. Это список данных и действий, к которым приложение получит доступ после авторизации.
Добавляем роуты для callback_url — config/routes.rb
Теперь мы готовы реализовать логику регистрации и авторизации.
Регистрация и Авторизация
Общий план.
- Принять данные от социальной сети
- Привести их к единому формату
- Сохранить в базу, создать нового пользователя
- Авторизовать нового пользователя
Для хранения социальных профилей будем использовать таблицу social_profiles(int: user_id, string: access_token, string: secret_key, bool: valid_tokens).
То есть мы сохраняем токен и прикрепляем его к пользователю. Если же юзер хочет поменять свой пароль от социальной сети, его токен становится невалидным. В таком случае мы помечаем его профиль и просим переподключить социальный аккаунт.
Примечание: этот пункт не нужен, если социальная сеть используется только для авторизации.
Мы должны определить в контроллере по экшену на каждую используемую социальную сеть. Но для обработки этих данных достаточно легко использовать метапрограммирование и написать один универсальный обработчик. Давайте его разберем немного подробнее.
Сохраняем данные авторизации в переменную для более удобного использования.
Логинимся с полученными данными (предварительно их нормализуем). Если пользователь пришел к нам впервые — мы его регистрируем.
После регистрации пользователя, мы сохраняем данные, полученные из социальной сети в его профиль, а также создаем (обновляем) его социальный профиль
Оставшаяся часть контроллера не так интересна (банальное приведение данных к единому формату). Давайте лучше рассмотрим подводные камни такой логики при использовании гема “devise”.
Проблема заключается в том, что по умолчанию “devise” накладывает индекс уникальности на поле email при создании таблицы пользователей. Социальные сети обычно не присылают электронный адрес пользователя. Поэтому у нас, во-первых — не проходит валидация email, во-вторых — даже если мы ее уберем, база позволит сохранить пустое значение всего один раз. Второй раз оно уже не будет уникальным.
В такой ситуации многие используют подход с генерацией случайного адреса. Но у нас нет желания писать логику, которая будет поддерживать эти костыли.
И пишем модуль для регистрации через социальные сети:
Код логики регистрации и авторизации говорит сам за себя. Нам же интересны те два метода, которые необходимо переопределить.
То есть мы проверяем, есть ли у нас социальные профили и в зависимости от этого смотрим нужно ли нам валидировать email.
Вот и все. Никакой магии. Следуя приведенным инструкциям, вы также сможете начать извлечение и обработку данных из API социальных сетей. Во второй части мы расскажем, как организовать код для работы с социальными сетями. Не переключайтесь!
