вопрос по GWT, Cookies и управлению веб-страницей

Question

Я использую GWT для создания веб-сайта. Этот вопрос касается страницы входа и файлов cookie для сохранения данных входа. GWT позволяет создавать веб-сайт на одной веб-странице.

мое приложение работает на одной веб-странице. У меня есть приложение, настроенное как, есть окно входа в систему с кнопкой входа в систему, и если детали верны, оно загрузит базовый интерфейс и удалит окно входа.

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

также кнопка выхода из системы в веб-приложении удалит информацию из файла cookie и выведет вас на страницу входа в систему (удалите информацию из файла cookie и направит вас к части входа на веб-странице).

или будет другой подход.

Answer 1

Я бы сказал, что вы почти правильно поняли: D Вот как я обрабатываю вход / выход из моего приложения:

1. Пользователь загружает страницу - если у него есть файл cookie, установленный с токеном (дополнительную информацию см. В следующих пунктах), отправьте этот токен на сервер, чтобы проверить, все еще ли он действителен. Если он действителен, вы вошли в систему, перейдите к пункту 5. См. Примечания ниже о том, как обрабатывать недействительный токен.
2. Пользователь вводит комбинацию пользователь / пароль. Эта информация отправляется на сервер (было бы лучше отправить ее по зашифрованному соединению, но с GWT это трудно сделать - например, см. этот вопрос ).
3. Сервер проверяет, совпадает ли комбинация пользователя / хеш пароля (см. Ниже) с тем, что находится в базе данных / что угодно. Если это так, он генерирует токен (просто некоторую случайную, довольно длинную строку, такую ​​как UUID ) и отправляет ее обратно клиенту.
4. Если пользователь установил флажок «Запомнить меня» во время входа в систему, сохраните токен в cookie-файле с будущей датой истечения срока действия (см. Другие руководства / вопросы относительно рекомендуемого периода времени).
5. Когда клиент получает токен, он должен использовать его для каждого запроса к серверу, который должны выполнять только аутентифицированные пользователи. Там сервер проверяет, является ли токен действительным (необходимо отслеживать пары токен / пользователь / пользователь в вашей БД) и, если это так, авторизует транзакцию / что угодно. Вот подвох: если вы полагаетесь только на cookie, вы будете уязвимы для атаки XSRF . Вот почему вы должны также передать токен (куки передаются автоматически - вот почему возможна атака XSRF) как часть запроса (вы знаете, как дополнительное поле в JSON или поле в POJO, которое вы отправляете через GWT- RPC или даже в заголовке HTTP).
6. При явном выходе из системы (нажав ссылку «Выйти» и т. Д.) Отправьте на сервер информацию о том, что этот пользователь только что вышел из системы. Сервер должен затем удалить / сделать недействительным токен. Он должен делать это независимо от опции «Запомнить меня» - поскольку явный выход из системы означает, что пользователь хочет удалить регистрационную информацию на этом ПК / браузере и запретить другим входить в систему под своим именем. Если пользователь просто закрывает браузер / страницу и вы правильно установили файл cookie в пункте 4 (то есть, он не истечет при закрытии браузера - опять же, только если была выбрана опция «Запомнить меня»), при следующем посещении пользователь должен автоматически войти в систему в пункте 1.

Некоторые дополнительные заметки

• Это очень важно: не забудьте проверить на стороне сервера, совпадает ли токен, переданный через cookie, с токеном, переданным как часть запроса / полезной нагрузки.
• Не хранить пароли в вашей базе данных в виде простого текста - хранить хэши паролей. Используйте BCrypt для максимальной безопасности. Вот почему я написал, что вы должны сравнивать хэши паролей , а не реальные пароли.
• Когда сервер обнаруживает недопустимый токен, это может означать несколько вещей - от обычного до оповещения. В общем, хорошо регистрировать эти ситуации и регулярно проверять журналы на предмет любых ненормальных действий.
  1. Пользователь давно не посещал сайт и срок действия токена истек . Убедитесь, что вы правильно обрабатываете истечение срока действия токена на стороне клиента (правильные даты истечения срока действия в файлах cookie должны привести к тому, что пользователь будет перенаправлен на страницу входа без отправки токена с истекшим сроком действия) и на стороне сервера (специальная задача, которая ежедневно просматривает список токенов и удаляет истек?)
  2. Возможно, вы наложили другие ограничения на проверку токена - например, токен не может быть просрочен и текущая попытка должна быть с того же IP, что и токен был изначально создан для.
  3. Произошла ошибка при отправке запроса , и он был искажен / поврежден - с этим ничего не поделаешь, но перенаправьте пользователя на страницу входа
  4. Сторонний пользователь пытается войти, используя токен ручной работы . Если вы используете глупо легко угадываемые токены (например, основанные на имени пользователя, rot13, собственном супер-специальном-потрясающем «шифровании» и т. Д.), То вам рано или поздно придется укусить 1071 UUID является примером хорошего кандидата токенов - как следует из названия, это универсально уникальный идентификатор - это означает, что никакие два пользователя не должны иметь одинаковые UUID, а сами UUID являются случайными и длинными.

Безопасность в приложениях AJAX - серьезный бизнес - я видел слишком много веб-приложений с легкими в использовании дырами в безопасности ... Убедитесь, что вы понимаете полностью что и для чего вы делает. Если у вас есть какие-либо вопросы, не стесняйтесь спрашивать:)

---

Обновление 2015-06-12: GWT - RPC безопасности XSRF

Answer 2

Здесь вы можете найти некоторую информацию о безопасности входа в GWT.Также есть раздел о том, как использовать куки, чтобы помнить, что пользователь вошел в систему.

Answer 3

Вот лучшая ссылка, через которую я прошел (с полным implementation). Полный цикл входа с сохранением cookie (sessionId).

Было бы намного лучше, если бы у вас была опция "Remember me"

Управление сессиями в GWT