Поддержка анонимных и зарегистрированных пользователей

Question

Я пытаюсь создать RESTful API для игры.

Игра будет поддерживать как анонимных пользователей (пользователей, которые просто хотят играть сейчас), так и пользователей, которые хотят зарегистрироваться.

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

GET users/create Users.create создаст нового «анонимного» пользователя, который вернет обратно пользователя (и уникальный токен, по которому его можно будет определить)

POST users/register Users.register примет необязательный токен (если пользователь ранее был анонимным), адрес электронной почты и пароль. Он создаст нового зарегистрированного пользователя (с тем же токеном, если он был предоставлен - или новым).

POST auth/login Auth.login примет адрес электронной почты и пароль, вернув пользователя в случае успеха

POST auth/authenticate будет принимать уникальный токен, возвращая 200/500 в зависимости от того, существует ли токен в базе данных.

По сути, для каждого звонка на сервер требуется один из этих уникальных токенов. Я буду в состоянии использовать это, чтобы отследить, с каким пользователем это связано.

Моя настоящая путаница возникает при попытке реализовать какую-то функцию «запомнить меня» для зарегистрированных пользователей. Если зарегистрированный пользователь имеет один из этих уникальных токенов, могу ли я использовать его как токен запомнить меня? Похоже, что это плохой выбор с точки зрения безопасности, и это может привести к большому количеству auth/authenticate сбоев. Поскольку новые токены необходимо создавать каждый раз, когда пользователь входит в систему на новом компьютере.

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

Приветствия

Ian

Answer 1

Токен (в качестве уникального идентификатора в файле cookie, хранящемся в браузере) - это единственный (насколько мне известно) способ, который вы можете использовать для уникальной идентификации пользователя, учитывая, что Play не имеет состояния.

Ключом будет не отправка токена в качестве параметра запроса, а извлечение его из файла cookie (сеанса воспроизведения) непосредственно при каждом запросе.

Что касается безопасности, она должна быть относительно безопасной. Cookie-файлы в Play защищены криптографически, что означает, что их нельзя изменить или подделать. Если вы добавляете SSL поверх них, их не нужно обнюхивать, поэтому никто не сможет «подделать» другого пользователя. Для дальнейшего улучшения этого используйте UUID (сложнее генерировать действительный токен), и он должен работать.

Фактически, когда вы думаете об этом, единственный способ провести «сеанс» в Play - это сохранить идентификатор пользователя (или некоторый идентификатор) в файле cookie приложения, что, в основном, и нужно.

О, и, как заметил Брайан Келли, не используйте GET для создания пользователя

Answer 2

Проверяли ли вы руководство по безопасности игры .Особенно часть о подделке межсайтовых запросов.
Play использует checkAuthenticity () метод для проверки подлинности каждого пост-запроса.
Убедитесь, что вы используете # {form} тег, который включает маркер подлинности в форме.В качестве альтернативы используйте тег # {authenticityToken /} в обычном HTML-теге формы.