В моем проекте используются Node.js и Express, но вопрос касается общего подхода.
Наши пользователи все из FB, и у нас нет никаких полномочий, кроме FB. Нам нужно связать некоторые действия с конкретными пользователями FB, а также нужно, чтобы их токены связывались с FB.
В настоящее время мы делаем это так:
- пользователь приходит на страницу
- есть невидимые блоки: один с заполнителями для аватара пользователя и имени ( "вошел в систему" ), другой с кнопкой, запускающей логин FB ( "выведенный из системы" )
- используя FB JS SDK, мы проверяем статус входа пользователя. Если подключен (что на самом деле означает: зарегистрировался в FB, аутентифицировал наше приложение и предоставил все необходимые нам разрешения), мы получаем имя пользователя и идентификатор FB и показываем блок "вошедший в систему". В противном случае отображается "выведенный" блок
- для зарегистрированных пользователей по некоторым действиям пользователь access_token передается на сервер через AJAX (здесь нет проблем, HTTPS) и используется кодом сервера для действий, таких как публикация на стене пользователя или что-то в этом роде
- кнопка входа FB обрабатывается JS и вызывает FB.login()
- в событии JS authResponseChanged предпринимаются очевидные действия (показать/скрыть заблокированные блоки входа/выхода)
Что хорошего: мы всегда знаем, что статус пользователя эффективен (токен TTL больше, чем обычный срок жизни страницы, поэтому мы здесь хорошо).
Что нам не очень нравится: * токены на стороне клиента недолговечны (да, мы можем их обменять, но не хотим, чтобы мы могли найти любую альтернативу) * обычно требуется несколько запросов к FB (1 - загрузить JS SDK, 2 - получить статус входа), пока мы не сможем что-то показать. До тех пор, пока не будет заблокирован блок 'login' нашего сайта.
Какой вопрос?
Мы ищем оптимальный способ использования некоторого кода на стороне сервера и, по крайней мере, отображаем имя пользователя и аватар, когда мы уверены, что пользователь вошел в систему.
Я могу представить себе такую схему, как это:
- используйте серверную авторизацию (с переадресацией), чтобы получить долгоживущий токен и сохранить его на сервере.
- сохранить статус пользователя (вход/выход, идентификатор FB, имя) в сеансе
- если сеанс имеет зарегистрированное состояние, отображаемое имя и аватар при обработке шаблонов на сервере
Обеспокоенность
- если пользователь зарегистрировал наше имя от FB или отмененного разрешения на использование приложения, как мы его узнаем, и когда мы его проверим (проверяйте каждый N-запрос каждые X часов? проверяйте только, когда токен истекает через Y часов?)
- если мы альтернативно проверяем статус пользователя с сервера перед визуализацией любого шаблона (что имеет место в официальном примере ), это замедлит работу не так ли? Потому что я думаю, что вызовы FB API могут быть довольно медленными в жаркие часы.
