Действительно ли сессии нарушают RESTfulness?

Использование сеансов в RESTful API действительно нарушает RESTfulness? Я видел много мнений, идущих в обоих направлениях, но я не уверен, что сессии проходят без REST . С моей точки зрения:

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

Так как сессии нарушают это?

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

Таким образом, для клиента cookie сеанса точно такой же, как и любой другой механизм аутентификации на основе заголовка HTTP, за исключением того, что он использует Cookieзаголовок вместо Authorizationили какой-либо другой частный заголовок. Если к серверной части значения cookie не был подключен сеанс, почему это могло бы изменить ситуацию? Реализация на стороне сервера не должна касаться клиента, пока сервер ведет себя RESTful. Таким образом, куки сами по себе не должны создавать API без REST , а сеансы - это просто куки для клиента.

Мои предположения неверны? Что делает сессионные куки RESTless ?

Сначала давайте определим некоторые термины:

• RESTful:

  Можно охарактеризовать приложения, соответствующие ограничениям REST, описанным в этом разделе, как «RESTful». [15] Если служба нарушает какое-либо из обязательных ограничений, ее нельзя считать RESTful.

  согласно википедии .

• ограничение без гражданства:

  Далее мы добавим ограничение к взаимодействию клиент-сервер: связь должна быть без состояния по своей природе, как в стиле клиент-сервер без состояния (CSS) в разделе 3.4.3 (рисунок 5-3), так что каждый запрос от клиента к Сервер должен содержать всю информацию, необходимую для понимания запроса, и не может использовать какой-либо сохраненный контекст на сервере. Поэтому состояние сеанса полностью сохраняется на клиенте.

  по Филдинговой диссертации .

Таким образом, сеансы на стороне сервера нарушают ограничение REST без сохранения состояния, и поэтому RESTfulness тоже.

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

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

На мой взгляд, нет ничего плохого в печенье. Технология cookie - это механизм хранения на стороне клиента, в котором хранимые данные автоматически присоединяются к заголовкам cookie при каждом запросе. Я не знаю ограничения REST, которое имеет проблемы с такими технологиями. Таким образом, нет никаких проблем с самой технологией, проблема с ее использованием. Филдинг написал подраздел о том, почему он считает, что HTTP-куки - это плохо.

С моей точки зрения:

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

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

• Рисунок 1. - Аутентификация без сохранения состояния доверенными клиентами

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

Теперь это работает довольно хорошо доверенными клиентами, написанными вами, но как насчет сторонних клиентов? Они не могут иметь имя пользователя и пароль, а также все разрешения пользователей. Таким образом, вы должны отдельно хранить разрешения, которые может иметь сторонний клиент для конкретного пользователя. Таким образом, разработчики клиентов могут зарегистрировать своих сторонних клиентов и получить уникальный ключ API, а пользователи могут разрешить сторонним клиентам получать доступ к некоторой части своих разрешений. Например, чтение имени и адреса электронной почты, перечисление их друзей и т. Д. После разрешения стороннего клиента сервер сгенерирует токен доступа. Эти токены доступа могут использоваться сторонним клиентом для доступа к разрешениям, предоставленным пользователем, например:

• Рисунок 2. - Аутентификация без сохранения состояния сторонними клиентами

Таким образом, сторонний клиент может получить токен доступа от доверенного клиента (или напрямую от пользователя). После этого он может отправить действительный запрос с ключом API и токеном доступа. Это самый основной сторонний механизм аутентификации. Вы можете прочитать больше о деталях реализации в документации каждой сторонней системы аутентификации, например, OAuth. Конечно, это может быть более сложным и более безопасным, например, вы можете подписать детали каждого отдельного запроса на стороне сервера и отправить подпись вместе с запросом и т. Д. Фактическое решение зависит от потребностей вашего приложения.

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

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

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

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

Я надеюсь, что все это имело смысл. Вам также следует ознакомиться с разделом «Ограничения» статьи в Википедии о передаче представительского состояния, если вы этого еще не сделали. Это особенно поучительно в отношении того, о чем на самом деле спорят принципы REST и почему.

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

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

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

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

На самом деле, RESTfulness применяется только к RESOURCES, как указано универсальным идентификатором ресурса. Так что даже говорить о таких вещах, как заголовки, куки и т. Д. В отношении 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 переходит от одного устойчивого состояния к следующему, и каждое такое устойчивое состояние является одновременно потенциальным начальным состоянием и потенциальным конечным состоянием. То есть система RESTful представляет собой неизвестное число компонентов, подчиняющихся простому набору правила таковы, что они всегда находятся в состоянии REST или переходят из одного состояния RESTful в другое состояние RESTful. Каждое состояние может быть полностью понято представлением (ями), которые оно содержит, и набором переходов, которые оно обеспечивает, с переходами, ограниченными униформой набор действий, которые должны быть понятны. Система может представлять собой сложную диаграмму состояний, но каждый пользовательский агент может видеть только одно состояние за раз (текущее устойчивое состояние), и, таким образом, каждое состояние является простым и может анализироваться независимо. Пользователь OTOH может создавать свои собственные переходы в любое время (например, ввести URL, выбрать закладку,открыть редактор и т. д.).

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

Например, когда пользователь вводит данные в экран графического интерфейса, клиент отслеживает, какие поля были введены, а какие нет, какие-либо обязательные поля отсутствуют и т. Д. Это все КЛИЕНТСКИЙ КОНТЕКСТ, и его не следует отправлять или отслеживать на сервере. На сервер отправляется полный набор полей, которые необходимо изменить в ресурсе IDENTIFIED (посредством URI), чтобы в этом ресурсе происходил переход из одного состояния RESTful в другое.

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

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

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

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

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

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

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

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

я думаю, что токен должен включать в себя всю необходимую информацию, закодированную внутри него, что делает аутентификацию путем проверки токена и декодирования информации https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/

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