В настоящее время я создаю сайт, используя GWT, размещенный на AppEngine. Я делаю это со своими собственными логинами, которые делаю (я знаю, что Google предоставляет что-то с GWT, но мне нужна моя собственная система входа), и я уже довольно давно пытаюсь определить сеансы. Я нашел несколько руководств, и один из сайтов, который я читал, это http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ
Существует раздел "Как запомнить логины". Я знаю, как получить идентификатор сеанса и сохранить его на клиенте в файле cookie с помощью вызова RPC. Я не понимаю, что через день или около того пользователь возвращается, и я должен получить идентификатор сеанса из файла cookie и отправить его обратно на сервер. Что я должен делать на сервере, чтобы безопасно оценить, является ли идентификатор сеанса все еще допустимым, и получить всю необходимую информацию о пользователе?
Дополнительные вопросы: 1. Что заставит изменить идентификатор сеанса? 2. Что, если пользователь был на ноутбуке, а пользователь ушел в другое место. Сможет ли он по-прежнему безопасно войти в систему без повторного ввода логина и пароля?
Спасибо!
~ Скотт
Аналогичный вопрос: вопрос о GWT, файлах cookie и управлении веб-страницами .
Вы должны помнить одну важную вещь: не полагайтесь только на файлы cookie - также перенесите идентификатор сеанса / токен в полезную нагрузку запроса и сравните его со значением cookie на стороне сервера. Это предотвратит атаки XSRF. Это то, о чем вам следует беспокоиться.
Политика того, как работать с идентификаторами сеанса, зависит от того, насколько серьезно вы относитесь к безопасности в своем приложении и какой это тип приложения.Например, вы можете войти в систему с одним и тем же токеном в GMail с разных IP-адресов - я предполагаю, что они разрешили это, потому что обычно IP-адрес пользователя изменяется во время сеанса. Однако они добавили функцию, которая позволяет вам видеть, с каких IP-адресов пользователь недавно вошел в систему. И не забывайте о пользователях с динамическими IP-адресами (довольно большое количество) - если вы отслеживаете токены и IP-адреса, вы в основном запрещаете этим пользователям оставаться в системе между сеансами.
Что мне делать на сервере чтобы надежно оценить, если идентификатор сеанса все еще допустим, и подтяните вся необходимая информация о пользователь?
Вы должны отслеживать пары идентификаторов сеанса / входа в систему в своей БД.
Что может привести к изменению идентификатора сеанса?
Либо срок его действия истекает, либо пользователь пытается войти в систему с токеном, не привязанным к его IP. Вы также можете добавить свои собственные правила - например, количество входов в систему и т. Д. Для дополнительной безопасности вы можете генерировать новый идентификатор сеанса / токен при каждом новом входе в систему / сеанс (пользователь аутентифицируется со старым токеном, сервер проверяет его действительность. и отправляет пользователю новый токен, который он должен использовать с этого момента).
Чтобы запомнить логины, вам необходимо безопасно сгенерировать уникальный идентификатор сеанса. Обычно это помещается в файл cookie. Я бы порекомендовал использовать фреймворк, который делает для вас файлы cookie сеанса. Ошибки могут сделать ваш сайт открытым для злоупотреблений. На что следует обратить внимание:
Ответы на ваши дополнительные вопросы есть.