Придерживаться моего оружия REST или отсутствия гражданства повреждения? Совет необходим
Я записал УСПОКОИТЕЛЬНЫЙ сервлет, и разработчик UI хочет сохранить зарегистрированное состояние на сервере.
Он предъявил эту странную претензию: "Я не встретился с производством реализация REST, которая является чистым REST. Те, которые я видел, что у всех есть сервер, поддерживают сессию".
Я нахожу это трудным принять. Сначала существует техническая особенность, что существует много простых страниц HTTP там, все ЧИСТО УСПОКОИТЕЛЬНЫЕ. Во-вторых, да, существуют неуспокоительные реализации, маркировал RESTful, точно так же, как существует медь маркированное "золото". В-третьих, просто потому что все остальные спрыгивают из моста, не означает, что я должен.
Фон: это - веб-приложение Ajax JavaScript с помощью HTTPS и Стандартной аутентификации. Для предотвращения обычного (uncustomizeable) всплывающего поля входа в систему браузера приложение показывает экран входа в систему с логотипом продукта и текстовыми полями для имени и пароля. Имя и пароль хранится в документе и отправляется в заголовке Авторизации за каждым запросом. Если Вы обновляете страницу, имя и пароль потеряны, и пользователь должен ввести их снова. Это рассмотрело ошибку; разработчик UI хочет смочь нажать кнопку Обновить, не давая пароль снова.
Таким образом, разработчик хочет использовать cookie или сессию JSP. Abby, действительно ли это верно, что в конце каждая реализация REST поддерживает состояние приложения на сервере? Или есть ли способ, которым я могу решить эту проблему и все еще поддержать мою УСПОКОИТЕЛЬНУЮ чистоту?
4 ответа
Я думаю, что по практическим причинам (в основном, для возможности просмотра) вам нужно различать состояние приложения и состояние аутентификации. Я не могу вспомнить ни одного механизма аутентификации, который бы не сохранял некоторую форму состояния на стороне сервера.
Что действительно важно, так это то, насколько он отделен от приложения. Например, HTTP Digest сохраняет некоторую форму состояния на сервере, но это явно абстрагировано как часть обычных WWW-Authenticate и Authorization переговоров по заголовкам. Поскольку большинство браузеров поддерживают это нативно, это ортогонально приложению и как таковое не нарушает принцип безстатичности REST.
В настоящее время, поскольку у пользователей есть некоторые эстетические ожидания, которым не соответствует аутентификация HTTP Basic/Digest в браузерах, веб-сайты склонны использовать аутентификацию на основе форм и, впоследствии, cookies. По правде говоря, это не только то, как это выглядит, это также вопрос удобства использования (например, информация "забыл пароль", хотя она может быть в теле ответа 401) и безопасности. Браузеры не позволяют вам легко отходить от базовой/дайджест/сертификатной аутентификации, если только это не сделано полностью в Ajax на одной странице, как вы упомянули, и это может помочь CSRF.
Я думаю, что cookies приемлемы для аутентификации, но убедитесь, что вы не храните переменные, связанные с приложением, в сессии.
Вы можете прочитать некоторые комментарии Роя Филдинга на эту тему:
Аутентификация ортогональна. Cookies также ортогональны, когда они просто используются для согласования содержимого или аутентификации. Однако Cookie аутентификация не допускается в REST потому что она не имеет видимости, что вызывает проблемы с безопасностью, потому что другие компоненты не знают, что это конфиденциальная информация.
EDIT (дополнительные комментарии по аспектам безопасности):
Я понимаю, что комментарии Роя Филдинга в сообщении, которое я процитировал, направлены против cookies по причинам безопасности. Конечно, он прав. Однако, на мой взгляд, защитить от CSRF с помощью Basic/Digest/Cert (который в 2003 году, когда появилось это сообщение, еще не был на радаре) сложнее, чем от кражи куки. Конечно, это зависит от реализации. Идеального решения нет, но если вы используете куки, используйте безопасные куки, по HTTPS.
Я не вижу проблем с использованием cookie для хранения этой информации на стороне клиента. Файлы cookie становятся проблемой только тогда, когда они используются в качестве указателей на некоторое состояние сеанса на стороне сервера.
Главное, о чем вы должны беспокоиться, - это безопасность информации в куки. Вероятно, вы не захотите помещать пароль в виде открытого текста в файл cookie: -)
- По умолчанию браузеры не запрашивают мандаты при обновлении страницы. Возможно, вам стоит обратить на это внимание, потому что если вы это исправите, то ваша проблема будет решена.
- Вы можете поддерживать REST-сервис по большей части, за исключением того, что пользователь может аутентифицироваться либо с помощью HTTP, либо с помощью cookie. Т.е. сервис работает и в том случае, если у вас нет cookie.
Regards,
Abby.
Если после аутентификации вы возвращаете какой-либо идентификатор сессии и передаете его при каждом вызове, это не сильно отличается от передачи учетных данных аутентификации при каждом вызове. С точки зрения производительности, последний может кэшировать учетные данные, так что производительность не пострадает. С точки зрения безопасности, отсутствие необходимости хранить учетные данные лучше, поскольку сеансы истекают, а учетные данные (обычно) нет. Возможно, отказ от сессий более надежен, поскольку сервер может забыть обо всем между вызовами, но при этом продолжать работать.
Короче говоря, нет ни одного весомого аргумента в ту или иную сторону, и вам, вероятно, не стоит зацикливаться на том, достаточно ли вы "чисты" в своей приверженности REST. Настоящий вопрос заключается в поведении клиента, и это то, что вы можете настроить независимо от этого, как предлагает Sjoerd.