Как безопасно передавать Facebook Id с клиента на сервер
у меня есть приложение Facebook canvas. Я использую JS SDK для аутентификации пользователя на стороне браузера и запроса различной информации через FB.api (например, имя, друзья и т. д.).
Я также хочу сохранить некоторую дополнительную информацию о пользователе (не удерживаемую на Facebook) в базе данных на моем сервере, сделав вызов ajax:
{ userFavouriteColour: "Red" }
чтобы сохранить это на сервере и связать с правильным пользователем, мне нужно знать uid Facebook, и это представляет проблему. Как мне пройти uid от клиента к серверу.
Вариант 1: добавьте uid в запрос ajax:
{ uid: "1234567890",
userFavouriteColour: "Red" }
это явно не хорошо. Было бы тривиально для любого сделать запрос ajax к моему веб-сервису, используя чей-то идентификатор Facebook и изменить свой любимый цвет.
Вариант 2: на сервере извлеките uid из файла cookie: Это вообще возможно? Я читал, что Facebook устанавливает cookie, содержащий UID и токен доступа, но делает У меня есть доступ к cookies в своем домене? Что еще более важно, могу ли я безопасное извлеките uid из файла cookie или это открыто для подмены, как вариант 1.
Вариант 3: аутентификация на стороне сервера пользователя на сервере: Я мог бы использовать аутентификацию на стороне сервера для проверки удостоверения пользователя на моем сервере. Но будет ли это работать, если я уже использую аутентификацию на стороне клиента в браузере? Будет ли у меня два разных маркера доступа? Я хотел бы чтобы сделать ФБ.запросы api из браузера, поэтому мне нужен маркер доступа на клиенте (а не только на сервере).
это должен быть очень распространенный сценарий, поэтому я думаю, что мне не хватает чего-то фундаментального. Я прочитал много документации Facebook (различные потоки аутентификации, токены доступа, signed_request и т. д.) и много сообщений на SO, но я все еще не понимаю, как аутентификация на стороне клиента и аутентификация на стороне сервера хорошо сочетаются.
Короче, я хотите знать личность пользователя на сервере, но по-прежнему делать запросы к api Facebook из браузера клиента?
(Я использую ASP.NET и Facebook C# SDK на сервере)
редактировать: добавлено баунти. Я надеялся получить более действенную, официальную рекомендацию о том, как справиться с этой ситуацией, или даже пример. Как уже говорилось, Я уже прочитал много официальных документов FB по потокам аутентификации, но я все еще не могу найти ничего определенного о том, как клиентская и серверная аутентификация работают вместе.
4 ответов
Вариант 1: Самый простой способ, который я могу придумать, - включить accessToken в JS и передать его с помощью вызова ajax.
Вариант 2: Используя то же, что и вариант 1, но вместо отправки только accessToken, отправьте signedRequest.
на стороне сервера, вы можете расшифровать его с помощью (TryParseSignedRequest метод), который даст вам UserID : -)
Примечание: signedRequest шифруется с секретом приложения. вы единственный, кто должен знать, так что ты в безопасности.
предупреждение:
у меня нет опыта кодирования на C#, но небольшой поиск в google дал мне это:
Это очень просто на самом деле.
когда пользователь загружает приложение, используйте аутентификация на стороне сервера, получить маркер доступа и загрузить пользовательские данные, выдав запрос api с сервера.
На стороне сервера у вас будет все, что вам нужно, и это песочница.
когда страница отображается для пользователя, с помощью Яш СДК получить данные аутентификации пользователя, вы должны иметь возможность использовать FB.getLoginStatus С пользователем уже прошла аутентификацию на стороне сервера.
Теперь на стороне клиента у вас также есть маркер доступа, который вы можете использовать для получения пользовательских данных из graph api.
два токена будут разными, а также будут иметь разный срок действия, но это не должно быть проблемой, оба токена должны работать должным образом, как вы ожидаете.
Поскольку обе стороны имеют свой собственный токен и способ делать запросы к api, нет необходимости отправлять какие-либо данные fb между их.
Итак, 3-й вариант, который вы упомянули, для меня звучит лучше всего, и это действительно просто реализовать.
редактировать
все SDK facebook - это просто обертки для http-запроса, так как весь api FB сделан на http-запросах.
SDKs просто дает вам легкий и более короткий доступ к данным без необходимости самостоятельно создавать url-адрес (со всеми возможными параметрами), делать запрос и анализировать ответ.
To будьте полностью честны, я думаю, что остановить предоставление способа для C# SDK поддерживать аутентификацию на стороне сервера-очень плохое решение.
Какой смысл предоставлять SDK, который не реализует весь api?
лучшим ответом на ваш вопрос, по моему опыту, является использование аутентификации на стороне сервера и клиента, и поскольку C# SDK не поддерживает его, мой совет вам создать свой собственный SDK.
Это совсем не сложно, я уже реализовал его для python и java (дважды), и поскольку вы будете разрабатывать его для своих нужд, он может быть адаптирован для ваших конкретных потребностей, в отличие от общедоступного SDK, который должен поддерживать все возможные варианты.
2-е изд
нет необходимости создавать совершенно новый SDK, вы можете просто "расширить" те, которые вы используете, и добавить недостающие части, которые вам нужны, например, поддержку аутентификации на стороне sever.
Я не знаю, является ли это специфичным для языка, но использование аутентификации на стороне сервера и клиента не наносит вреда.
вы можете работать над вариантом 2, Но да, это также будет уязвимо для спуфинга.
делая вариант 3, у вас будет один токен доступа для этого сеанса пользователя, так что это был бы лучший выбор по моему мнению, так как у вас всегда есть шанс подмены при передаче информации о пользователе со стороны клиента.
недавно у меня был точно такой же вопрос. Это вариант 2. Проверка этот пост из блога Facebook.
честно говоря, я недостаточно хакер, чтобы знать, можете ли вы подделать UID в cookie, но это, похоже, "официальный" способ сделать это.
EDIT: к другому вопросу в опции 2, Да, я считаю, что вы должны получить доступ к этому cookie в своем домене.