Аналогичный вопрос: вопрос по GWT, cookie-файлам и управлению веб-страницей .
Следует помнить одну важную вещь: не полагайтесь только на файлы cookie - перенесите идентификатор сессии / токен в полезную нагрузку запроса и сравните его со значением файла cookie на стороне сервера. Это предотвратит атаки XSRF. Это то, о чем вы должны беспокоиться.
Политика в отношении того, как обращаться с идентификаторами сеансов, зависит от того, насколько серьезно вы относитесь к безопасности в своем приложении и к какому типу приложений. Например, вы можете войти в систему с одним и тем же токеном в GMail с разных IP-адресов - я полагаю, что они допустили это, потому что обычно IP-адрес пользователя меняется во время сеансов. Однако они добавили функцию, которая позволяет вам видеть, с каких IP-адресов пользователь недавно вошел в систему. И не забывайте о пользователях с динамическими IP-адресами (довольно большое количество) - если вы будете отслеживать токены и IP-адреса, вы в основном не допустите, чтобы эти пользователи оставались в системе между сеансами.
Что я должен делать на сервере
для того, чтобы надежно оценить, если
Идентификатор сеанса все еще допустим, и подтяните
вся необходимая информация о
пользователь?
Вы должны отслеживать идентификаторы сессии / пары входа в вашу БД.
Что изменит идентификатор сеанса?
Либо истекает срок действия, либо пользователь пытается войти в систему с токеном, который не привязан к их IP-адресу. Вы также можете добавить свои собственные правила - например, количество входов в систему и т. Д. Для дополнительной безопасности вы можете генерировать новый идентификатор / токен сеанса при каждом новом входе в систему / сеанс (пользователь аутентифицируется со старым токеном, сервер проверяет его действительность). и отправляет обратно пользователю новый токен, который он / она должен использовать с этого момента).