Могу ли я использовать идентификатор сеанса в REST API? [Дубликат]

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

Вы можете объединиться, чтобы объединиться следующим образом: usernameRole: пароль, но это плохая практика, и это также неэффективно, потому что, когда у пользователя больше ролей , механизм проверки подлинности должен будет проверить все роли в конкатенации и повторить каждый вызов. Это уничтожит одно из самых больших технических преимуществ RBAC, а именно очень быстрый авторизационный тест.

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

Чтобы решить эту проблему, требуется сеансовое сопровождение, и это кажется, по некоторым ответам, противоречащим REST.

Вот что мне нравится в ответе, что REST не следует рассматривать как религию. Например, в сложных бизнес-ситуациях, в сфере здравоохранения, RBAC является абсолютно общим и необходимым. И было бы жаль, если бы им не разрешалось использовать REST, потому что все дизайнеры REST-инструментов рассматривали бы REST как религию.

Для меня не так много способов поддерживать сеанс по HTTP. Можно использовать файлы cookie с sessionId или заголовок с sessionId.

Если у кого-то есть другая идея, я буду рад это услышать.

1. Сеансы не RESTless
2. Вы имеете в виду, что служба REST только для http-use или у меня что-то не так? Сеанс на основе файлов cookie должен использоваться только для собственных (!) Http-сервисов! (Это может быть проблемой для работы с файлом cookie, например, с помощью Mobile / Console / Desktop / и т. Д.)
3. , если вы предоставляете услугу RESTful для разработчиков сторонних разработчиков, никогда не используйте сеанс на основе файлов cookie, вместо этого используйте токены избегайте проблем с безопасностью.

Файлы cookie не предназначены для аутентификации. Зачем изобретать колесо? У HTTP есть хорошо разработанные механизмы аутентификации. Если мы используем файлы cookie, мы используем HTTP только в качестве транспортного протокола, поэтому нам необходимо создать нашу собственную систему сигнализации , например, чтобы сообщить пользователям, что они поставили неправильную аутентификацию (с использованием HTTP 401 будет неверно, поскольку мы, вероятно, не будем поставлять Www-Authenticate клиенту, поскольку спецификации HTTP требуют :)). Следует также отметить, что Set-Cookie является лишь рекомендацией для клиента. Его содержимое может быть сохранено или не сохранено (например, если файлы cookie отключены), а заголовок Authorization отправляется автоматически по каждому запросу.

Другое дело, что для получения файла авторизации вы, вероятно, захотите сначала предоставить свои учетные данные? Если да, то разве это не RESTless? Простой пример:

• Вы пытаетесь GET /a без cookie
• Вы получаете запрос авторизации каким-либо образом
• Вы идете и авторизуетесь каким-то образом, как POST /auth
• Вы получаете Set-Cookie
• Вы пытаетесь GET /a с cookie. Но GET /a ведет себя идемпотентно в этом случае?

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

Фактически, RESTfulness применяется только к RESOURCES, как указано универсальным идентификатором ресурса. Поэтому даже говорить о вещах, таких как заголовки, файлы cookie и т. Д. В отношении REST, не очень уместно. REST может работать над любым протоколом, хотя это обычно выполняется по HTTP.

Основным определяющим является следующее: если вы отправляете вызов REST, который является URI, то, как только вызов успешно завершен на сервер, делает ли этот URI один и тот же контент, если не выполняются переходы (PUT, POST, DELETE)? Этот тест будет исключать ошибки или запросы на аутентификацию, которые будут возвращены, поскольку в этом случае запрос еще не дошел до сервера, то есть сервлет или приложение, которое вернет документ, соответствующий данному URI.

Аналогично, в случае POST или PUT вы можете отправить заданный URI / полезную нагрузку и независимо от того, сколько раз вы отправляете сообщение, оно всегда будет обновлять одни и те же данные, чтобы последующие GET вернули согласованный результат?

REST - это данные приложения, а не информация о низком уровне, требуемая для передачи этих данных.

В следующем сообщении в блоге Рой Филдинг дал хорошее резюме всей идеи REST:

http://groups.yahoo.com/neo/groups/rest -discuss / conversations / topics / 5841

«Система RESTful переходит из одного стационарного состояния в другое, и каждое такое установившееся состояние является как потенциальным стартовым состоянием, так и потенциальным концом -state. Т.е. система RESTful представляет собой неизвестное количество компонентов, подчиняющихся простому набору правил, так что они всегда либо находятся в REST, либо переходят из одного состояния RESTful в другое состояние RESTful. Каждое состояние может быть полностью понято представлением (s ) он содержит и набор переходов, которые он предоставляет, причем переходы, ограниченные единым набором действий, должны быть понятны. Система может быть диаграммой сложного состояния, но каждый пользовательский агент может видеть только одно состояние за раз ( текущее установившееся состояние), и, таким образом, каждое состояние является простым и может быть проанализировано независимо. Пользователь OTOH может создавать свои собственные переходы при любом ti (например, введите URL-адрес, выберите закладку, откройте редактор и т. д.).

Переход к проблеме аутентификации, будь то с помощью файлов cookie или заголовков, до тех пор, пока информация не является частью URI и полезной нагрузки POST, она вообще не имеет никакого отношения к REST. Итак, что касается состояния без гражданства, мы говорим только о данных приложения.

Например, когда пользователь вводит данные в экран графического интерфейса, клиент отслеживает, какие поля были введены, что нет, никаких обязательных полей, которые отсутствуют. Это все CLIENT CONTEXT и не следует отправлять или отслеживать на сервере. То, что отправляется на сервер, - это полный набор полей, которые необходимо изменить в ресурсе IDENTIFIED (посредством URI), так что переход происходит на этом ресурсе из одного состояния RESTful в другой.

Таким образом, клиент отслеживает, что делает пользователь, и только отправляет логически завершенные переходы состояния на сервер.

Прежде всего, REST не является религией и к нему нельзя подходить как таковой. Хотя преимущества услуг RESTful имеют преимущества, вы должны следовать только принципам REST, насколько они имеют смысл для вашего приложения.

При этом аутентификация и состояние стороны клиента не нарушают принципов REST. В то время как REST требует, чтобы переходы состояний были неактивными, это относится к самому серверу. В основе всего, все REST - это документы. Идея безгражданства заключается в том, что SERVER является апатридом, а не клиентами. Любой клиент, выдающий идентичный запрос (те же заголовки, файлы cookie, URI и т. Д.), Должен быть отправлен на одно и то же место в приложении. Если веб-сайт сохранил текущее местоположение пользователя и управляемую навигацию, обновив эту навигационную переменную на стороне сервера, REST будет нарушен. Другой клиент с идентичной информацией запроса будет отправлен в другое место в зависимости от состояния на стороне сервера.

Веб-службы Google являются фантастическим примером системы RESTful. Им требуется заголовок аутентификации с ключом аутентификации пользователя, который должен быть передан при каждом запросе. Это немного нарушает принципы REST, поскольку сервер отслеживает состояние ключа аутентификации. Состояние этого ключа должно поддерживаться, и у него есть какая-то дата / время истечения срока действия, после которого он больше не предоставляет доступ. Однако, как я упомянул в начале своего сообщения, необходимо принести жертву, чтобы приложение действительно работало. Тем не менее, токены аутентификации должны храниться таким образом, чтобы все возможные клиенты могли продолжать предоставлять доступ в течение их действительных времен. Если один сервер управляет состоянием ключа аутентификации до такой степени, что другой сервер с балансировкой нагрузки не может взять на себя выполнение запросов на основе этого ключа, вы начали действительно нарушать принципы REST. Службы Google гарантируют, что в любое время вы можете использовать токен аутентификации, который вы использовали на своем телефоне для сервера балансировки нагрузки A, и направить сервер баланса нагрузки B со своего рабочего стола и по-прежнему иметь доступ к системе и перенаправляться на одни и те же ресурсы, если запросы были идентичными.

Все, что все сводится к тому, что вам нужно убедиться, что ваши токены аутентификации проверены на наличие какого-либо хранилища резервной копии (базы данных, кеша и т. д.), чтобы обеспечить сохранение многие из свойств REST, насколько это возможно.

Надеюсь, все это имело смысл. Вы также должны проверить раздел ограничений статьи wikipedia о представлении State State Transfer , если вы еще этого не сделали. Это особенно интересно в отношении того, что на самом деле аргументируют и почему делают доводы REST.