вопрос на GWT, Cookie и направлении веб-страницы
я использую gwt для создания веб-сайта. этот вопрос расценивает страницу входа в систему и cookie для сохранения данных для входа в систему. GWT позволяет Вам создавать веб-сайт в единственной веб-странице.
мое выполнение приложения на одной веб-странице. мне настраивали приложение как, существует поле входа в систему с кнопкой входа в систему, и если детали будут корректны, то это загрузит базовый UI и удаляет поле входа в систему.
таким образом, это означает каждый раз, когда я обновляю свою страницу, которую приложение приносит мне к странице входа в систему. должен там так или иначе настроить cookie, которые содержат информацию пользователя, например, день, который ввел бы детали в поле входа в систему и регистрировался бы автоматически,
также кнопка выхода из системы в рамках веб-приложения удалила бы информацию в cookie и принесла бы Вам к странице входа в систему (удалите информацию о куки и направьте Вас к части входа в систему веб-страницы).
или там был бы другой подход.
2 ответа
Я бы сказал, что вы почти все правильно поняли :D Вот как я обрабатываю вход/выход в моем приложении:
- Пользователь загружает страницу - если у него установлен cookie с токеном (см. следующие пункты для получения дополнительной информации), отправьте этот токен на сервер, чтобы проверить, действителен ли он еще. Если он действителен, вы вошли в систему, переходите к пункту 5. Смотрите примечания ниже о том, как обрабатывать недействительный токен.
- Пользователь вводит комбинацию пользователь/пасс. Эта информация отправляется на сервер (лучше всего было бы отправлять ее по зашифрованному соединению, но этого трудно добиться с помощью GWT - например, см. этот вопрос).
- Сервер проверяет, совпадает ли хэш пользователя/пароля (см. ниже) с тем, что находится в базе данных/whatever. Если да, он генерирует токен (просто случайную, довольно длинную строку, например UUID) и отправляет его обратно клиенту.
- Если пользователь установил флажок "Запомнить меня" во время входа, сохраните токен в куки с будущей датой истечения срока действия (см. другие руководства/вопросы о рекомендуемом периоде времени).
- Когда клиент получает маркер, он должен использовать его для каждого запроса к серверу, который вы хотите, чтобы выполняли только аутентифицированные пользователи. Там сервер проверяет, действителен ли токен (вы должны отслеживать пары токен(ы)/пользователь в вашей БД), и если да, авторизует транзакцию/что угодно. Вот в чем загвоздка: если вы полагаетесь только на cookie, вы будете уязвимы для атаки XSRF. Вот почему вы должны передавать токен также (куки передаются автоматически - вот почему возможна атака XSRF) как часть запроса (например, как дополнительное поле в JSON или поле в POJO, которое вы отправляете через GWT-RPC, или даже в заголовке HTTP).
- При явном выходе из системы (нажатие на ссылку "Logout" и т.д.), отправлять на сервер информацию о том, что данный пользователь только что вышел из системы. Затем сервер должен удалить/недействить токен. Он должен сделать это независимо от опции "Запомнить меня" - поскольку явный выход из системы означает, что пользователь хочет удалить информацию о входе на этом компьютере/браузере и не дать другим войти под его именем. Если пользователь просто закрывает браузер/страницу и вы правильно установили cookie в пункте 4 (то есть, он не истекает при закрытии браузера - опять же, только если была выбрана опция "Запомнить меня"), при следующем посещении пользователь должен автоматически войти в систему в пункте 1.
Некоторые дополнительные замечания
- Это очень важно: не забывайте проверять на стороне сервера, равен ли токен, переданный через cookie, тому, который был передан в составе запроса/платежной нагрузки.
- Не храните пароли в вашей базе данных в виде обычного текста - храните хэши паролей. Используйте BCrypt для максимальной безопасности. Вот почему я написал, что вы должны сравнивать хэши паролей, а не сами пароли.
- Когда сервер сталкивается с недействительным токеном, это может означать несколько вещей - от обычного до предупреждающего. В общем, полезно регистрировать такие ситуации и регулярно проверять журналы на предмет аномальной активности.
- Пользователь долгое время не посещал сайт, и срок действия токена истек. Убедитесь, что вы правильно обрабатываете истечение срока действия токена на стороне клиента (правильные даты истечения срока действия cookies должны привести к тому, что пользователь будет перенаправлен на страницу входа, без отправки истекшего токена) и на стороне сервера (специальная задача, которая ежедневно сканирует список токенов и удаляет истекшие? )
- Возможно, вы наложили какие-то другие ограничения на проверку токенов - например, токен не может быть просроченными текущая попытка должна быть с того же IP, для которого токен был сгенерирован изначально.
- При отправке запроса произошла ошибка, и он пришел в искаженном/поврежденном виде - с этим ничего не поделаешь, только перенаправить пользователя на страницу входа
- Сторонний пользователь пытается войти в систему, используя созданный вручную токен. Если вы используете тупо легко угадываемые токены (например, основанные на имени пользователя, rot13, собственном супер-специально-удивительном "шифровании" и т.д.), то рано или поздно вы будете укушены этим. UUID является примером хорошего кандидата на токен - как следует из названия, это универсально уникальный идентификатор - это означает, что никакие два пользователя не должны иметь одинаковые UUID, а сами UUID случайны и длинны.
Безопасность в AJAX-приложениях - дело серьезное - я видел слишком много веб-приложений с легко эксплуатируемыми дырами в безопасности... Убедитесь, что вы понимаете полностью, что и зачем вы делаете. Если у вас есть вопросы, не стесняйтесь спрашивать :)
Обновление 2015-06-12: GWT - Security RPC XSRF
Здесь вы можете найти некоторую информацию о безопасности входа в GWT. Также есть раздел о том, как использовать файлы cookie, чтобы помнить, что пользователь вошел в систему.