Авторизованный Flash-клиент для подключения к Java-серверу - PullRequest
7 голосов
/ 22 февраля 2011

Я создаю игру Facebook на основе Flash с бэкэндом Java, и я планирую использовать подход RESTful для соединения двух из них (не постоянное сокетное соединение).Я использую библиотеку AS3 для подключения клиента к Facebook, поэтому там хранится информация о моем сеансе.Однако как авторизовать клиентские подключения обратно на сервер?Я не могу оставить открытыми обратные ссылки, так как это позволило бы людям манипулировать состоянием игры, не играя в игру.Мне нужно убедиться, что вызовы поступают от действительного клиента и через действительный сеанс.

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

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

Кто-то должен был решить эту проблему, но я не могу ее найти.

Ответы [ 2 ]

0 голосов
/ 27 февраля 2011

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

1) Свежий клиент подключается к серверу и получает токен, действительный в течение x раз.

2) Клиент имеетзапутанная часть кода, которая использует алгоритм для изменения токена (и этот алгоритм изменяется с некоторой частотой синхронно с сервером).Клиент использует алгоритм для изменения токена и включает его в следующий запрос к серверу.

3) Сервер знает исходный токен и алгоритм, поэтому теперь он может проверить, действителен ли новый токени это от действительного клиента.

4) Цикл продолжается.

Это не на 100% безопасно, так как кто-то действительно может потратить время и проанализировать общение и в конечном итоге понять схему, но выможет так много поиграться с алгоритмом и изменить его достаточно часто, чтобы кому-то было трудно его угадать.

Надеюсь, это поможет.

PS Приложение, о котором я говорю, используетэто было в производстве в течение прошлых 5 лет и получает ~ 300 000 уникальных пользователей в день, и никто еще не взломал.

0 голосов
/ 25 февраля 2011

Если вы используете Java в качестве бэкэнда, я бы рассмотрел использование BlazeDS .Это отличная библиотека для выполнения AMF-соединений (которые асинхронны, поэтому соответствуют вашим непостоянным требованиям к сокетам).Если вы вообще используете Spring на бэкэнде, я бы настоятельно рекомендовал использовать Spring-Flex .Это добавляет кучу вкусностей, которые делают доступными услуги AMF на одном дыхании.Кроме того, он добавляет хуки для простой интеграции Spring Security.

Для вещей oAuth я бы переместил часть oAuth на веб-сторону вместо флэш-клиента (что, я думаю, вы понимаетеДелай сейчас).Таким образом, вы можете аутентифицировать веб-сеанс на стороне сервера и защитить страницу, содержащую .swf.Затем, когда ваш пользователь загружает .swf в ваш код (при условии, что вы используете Spring Security, интегрированную в BlazeDS), вы можете вызвать cs.authenticated на вашем cs: mx.messaging.ChannelSet.Это будет работать, но может быть больше перефразировать, чем вы хотите.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...