Как реализовать «Register with Facebook» аналогично Instagram на server-side?

Question

[devel787]

Добрый день.

Есть задумка сделать мобильное приложение (Android, iOS), которое будет взаимодействовать с сервером через API.

На стороне сервера Django REST framework для API и небольшая самописная админ-панель на Django.

Регистрация пользователей предполагается через мобильное приложение и исключительно через Facebook (никаких регистраций с вводом email+password быть не должно). Случай один-в-один, как при использовании мобильного приложения для Instagram на Android.

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

Как я вижу задачу на текущий момент:
1) Пользователь установил наше приложение.
2) Пользователь открыл приложение и увидел экран для регистрации.
3) Пользователь выбрал ”Register with Facebook”.
4) Каким-то образом произошла проверка правильности входа в Facebook + на этом этапе на сервере мы должны создать нового пользователя или удостоверится, что такой пользователь уже существует -- каким образом мы можем проделать такое на сервере??
-- в какой момент времени и что именно сообщит мобильное приложение серверу для этой операции??
5) После “log in” наше приложение посылает запросы к АПИ с указанием конкретного пользователя (и его пароля?), который осуществил регистрацию/вход через соц. сеть.

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

Буду рад любым подсказкам.

Answer 1

[FanKiLL]

Пользователь нажимает на кнопку, вы берёте id юзера в фейсбуке он уникальный и другую инфу, так же можете взять access_token если хотите делать какие то запросы в фейсбук.

Далее, отсылаете id юзера на сервер он уникальный помните, смотрим если есть юзер с таким id от фейсбука. Если нет, значит - можно зарегестрировать юзера, делаем юзера и привязываем этот facebook id к нему. Всё теперь юзер зарегестрирован и к нему привязан facebook id.

Если он нажимает на кнопку в приложении - вы отсылаете facebook id и юзер с таким facebook id на сервере находится, можно считать это за логин и пропустить юзера в ваше приложение.

На пятый пункт, нет пароль передавать нельзя, при регистрации или логине (лучше при логине) генерируете юзеру уже свой access_token с которым он может обращаться к вашему серверу.
Свой access_token выдавать при логине или после регистрации.

Теперь когда у юзера есть access_token от вашего сервера, он может делать запросы к вашему api серверу. Это значит, что он должен присылать этот токен с каждым обращением к вашему серверу, как он будет это делать зависит от дизайна вашего api. У фейсбука это как параметр в URL.
Я предпочитаю, чтобы access_token присылали в http хедерах.

Примерно, так... Одним ответом тут не отписаться( Спрашивайте ответим.

Comments

[devel787]

Спасибо за ответ.
Хотел бы уточнить
> Далее, отсылаете id юзера на сервер
1) Это делает мобильное приложение?
2) Отправка id осуществляется в "открытом" виде?
3) Как отличить такой запрос от мобильного приложения от подобного запроса, который я сам сформирую и отправлю через `curl` из терминала?

[FanKiLL]

1) Да отсылает моб. приложение. После того как вы сделали как написал вам выше человек, повесили коллбек и авторизовались на фейсбуке. habrahabr.ru/post/135342

2)Да можно в открытом виде, не вижу ничего криминального. Можно зашифровать, благо и клиент и сервер пишете вы, тогда 3 пункт можно не делать принципе - если уверенны в шифровании.

3)Вот тут действительно проблема. по сути эта часть api у вас будет открыта, так как для логина у человека ещё нет вашего access_token.
Злоумышленник, может привязать любой ID фейсбука к аккаунту - но он этим ничего не добьётся.
Но да ладно. Вместе с ID, отправляйте на сервер access_token который выдал вам фейсбук для этого юзера и уже с сервера попробуйте получить например email юзера с api фейсбука - если access_token рабочий и ваш запрос пройдёт, значит юзер прислал верные данные а не просто в curl вбил рендомно id и токен.

[FanKiLL]

Насчёт третьего пункта ещё скажу, что это пробела всех api где есть открытая часть, например логин/регистрация.
Вы можете вместе с таким запросом отсылать какой то токен.
Тем самым клиент подпишет что это запрос от него.
Как сгенерить такой токен и как его распознать знаете только вы...)
Сейчас объясню.

Представьте как проверяют номера visa и других карточек - эти номера никуда не отправляют для проверки - чтоб сверится с базой данных или ещё каким - то хранилищем.
Сама комбинация цифр - если провести через определённые алгоритм можно сказать валидный номер (не рабочий или есть там деньги) а именно валидный.

Или как проверяют cd-key программы - тоже в этом духе
Вот такой токен вы можете отсылать в открытые участки api - для всего другого есть access_token.

Но если честно, я и сам не знаю как правильно защитить такие участки api.
Сколько не защищай всё равно, кто то как вы сказали сделает курлом прописав правильные параметры и токены/шмокены.

[FanKiLL]

У нас например в одном проекте, для этого генерировались такие временные токены.
1406640371030010763526548
Первые 10 цифр это timestamp время когда токен был сгенерирован, остальные 15 цифр, должны проверятся по определённому алгоритму. У нас это было просто, сумма всех 15 цифр должна быть mod 10, то есть делиться на 10 без остатка. Если отстатка нет значит токен валидный.

Так же имея время генерации токена, вы можете ограничить его жизнь, то есть на сервере проверять timestamp если например прошло больше 5 сек, после генерации такой токен вы не принимаете.

Это было временное решение, вы можете этот токен как то шифровать, перемешивать или через каждые 3 цифры подмешивать туда букву или какие то символы в виде маскировочного мусора, чтобы враги не догадались))
Главное потом этот мусор на сервере почистить чтоб получить первозданый токен 1406640371030010763526548
Можете ввести здесь www.onlineconversion.com/unix_time.htm первые 10 цифр от токена узнать когда он сгенерирован.

[devel787]

@FanKiLL ещё раз спасибо за разъяснения.

[FanKiLL]

@devel787 по сути эти временные токены, что-то вроде капчи.
Незачто, не знаю если я вам помог, или ещё больше запутал, тут по сути три разных токена, от фейсбука, ваш access_token + временный токен который отсылается и проверяется только на login и register запросах.

[FanKiLL]

Вот сейчас посмотрел как мы генерировали временные токены.
Немного переписал подмешиваю туда через каждую цифру одну букву. Вышло примерно так:

Shuffled Token: X1h4h0N6P6k6n6x9k6q2W|Q2W4A4f4x6K1i3r1T0f5Y2U4Z1x5X3
Full Token: 1406666962|244461310524153
Token: 244461310524153
Created Token TimeStamp: 1406666962
Created Token as Date: Sat Jan 17 08:44:26 IST 1970

StopWatch: Generate Token running time (millis) 6 milliseconds

Единственное, что в среднем генерация такого токена занимает 6-7 миллисекунд. Код на java, можно на android использовать.

Answer 2

[Константин]

В общих чертах:
в мобильном приложении пользователь нажимает на кнопку от фейсбука: https://developers.facebook.com/docs/android
Вы регистрируете в приложении callback который получит Sesssion, в котором будет access_token.
Далее вы посылаете инфу на сервер: fbid, access token... (и может быть ещё что-нибудь понадобится, я не знаю, серверную часть API я не писал).
После сервер обрабатывает ваш access token, может например спросит права, или спросит инфу пользователя, если всё в порядке,
тогда вы делаете запись в базу данных и возвращаете "уря, ты зашёл".

Костыли: 1. если вам ВДРУГ нужны права, а такое право - email (он хорош как уникальный id пользователя), права можно проверять с объекта Session, если вдруг не дал права, удаляете все права, и перезапрашиваете их заново, так как сервер это сделать не может.
2. acess token надо обновлять, он жив помоему примерно 30 дней.

-- каким образом мы можем проделать такое на сервере?? - запрос в граф апи на /me (https://developers.facebook.com/docs/graph-api/ref... )

PS: Помоему тут можно скачать FB APi https://github.com/sciyoshi/pyfacebook/ для присмыкающегося ползунка

Comments

[devel787]

Спасибо, почитаю подробнее.