Можете ли вы помочь мне понять это? «Распространенные ошибки REST: сессии не имеют значения»

Отказ от ответственности: я новичок в школе мысли REST, и я пытаюсь обдумать это.

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

Клиенту не нужно «входить в систему» ​​или «устанавливать соединение». HTTP-аутентификация выполняется автоматически для каждого сообщения. Клиентские приложения являются потребителями ресурсов, а не услуг. Поэтому не к чему войти! Допустим, вы бронируете рейс через веб-сервис REST. Вы не создаете новое «сеансовое» соединение с сервисом. Скорее вы просите «объект создателя маршрута» создать для вас новый маршрут. Вы можете начать заполнять пробелы, но затем получить какой-то совершенно другой компонент в другом месте в Интернете, чтобы заполнить некоторые другие пробелы. Нет сеанса, поэтому нет проблемы переноса состояния сеанса между клиентами. Также нет проблемы "сессионной близости"

Хорошо, я получаю, что HTTP-аутентификация выполняется автоматически для каждого сообщения - но как? Имя пользователя / пароль отправляется с каждым запросом? Разве это не увеличивает площадь поверхности атаки? Я чувствую, что мне не хватает части головоломки.

Было бы плохо иметь службу REST, скажем, /sessionкоторая принимает запрос GET, где вы передаете имя пользователя / пароль как часть запроса, и возвращает маркер сеанса, если аутентификация прошла успешно, это может быть прошло вместе с последующими запросами? Имеет ли это смысл с точки зрения REST, или это упущение?

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

Хорошо, я получаю, что HTTP-аутентификация выполняется автоматически для каждого сообщения - но как?

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

Было бы плохо иметь службу REST, скажем, / session, которая принимает запрос GET, в котором вы передаете имя пользователя / пароль как часть запроса, и возвращает маркер сеанса, если аутентификация прошла успешно, что могло бы затем будут переданы вместе с последующими запросами? Имеет ли это смысл с точки зрения REST, или это упущение?

Это не будет RESTful, поскольку оно несет состояние, но, тем не менее, оно довольно распространено, поскольку это удобно для пользователей; пользователь не должен входить каждый раз.

То, что вы описываете в «маркере сеанса», обычно называется cookie-файлом для входа . Например, если вы попытаетесь войти в свой Yahoo! В аккаунте есть флажок, который гласит "держи меня в сети в течение 2 недель". По сути, это означает, что (по вашим словам) «поддерживайте мой токен сессии в течение 2 недель, если я успешно войду в систему». Веб-браузеры будут отправлять такие файлы cookie для входа (и, возможно, другие) с каждым HTTP-запросом, который вы просите сделать для вас.

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

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

в вашем случае я говорю ДА, это RESTy, но старайтесь избегать использования нативных сессий php в вашем REST API и начинайте генерировать ваши собственные хешированные токены, срок действия которых истекает через определенный промежуток времени!

Нет, дело не в этом. Google ClientLogin работает именно таким образом, за исключением того, что клиент получает указание перейти в «/ сеанс» с помощью ответа HTTP 401. Но это не создает сеанс, а только создает способ для клиентов (временно) аутентифицировать себя, не передавая учетные данные в открытом виде, и для сервера контролировать достоверность этих временных учетных данных, как он считает нужным.

Хорошо, я получаю, что HTTP-аутентификация выполняется автоматически для каждого сообщения - но как?

«Авторизация:» HTTP-заголовок, отправленный клиентом. Либо основной (простой текст), либо дайджест.

Было бы плохо иметь службу REST, скажем, / session, которая принимает запрос GET, в котором вы передаете имя пользователя / пароль как часть запроса, и возвращает маркер сеанса, если аутентификация прошла успешно, что могло бы затем будут переданы вместе с последующими запросами? Имеет ли это смысл с точки зрения REST, или это упущение?

Вся идея сеанса состоит в том, чтобы создавать приложения с сохранением состояния, используя протокол без сохранения состояния (HTTP) и тупой клиент (веб-браузер), поддерживая состояние на стороне сервера. Один из принципов REST - «Каждый ресурс уникально адресуется с использованием универсального синтаксиса для использования в ссылках гипермедиа» . Переменные сеанса - это то, что не может быть доступно через URI. Поистине, приложение RESTful будет поддерживать состояние на стороне клиента, отправляя все необходимые переменные по HTTP, предпочтительно в URI.

Пример: поиск с нумерацией страниц. У вас будет URL в форме

http://server/search/urlencoded-search-terms/page_num

Это имеет много общего с закладками

Я думаю, что ваше предложение в порядке, если вы хотите контролировать время жизни клиентской сессии. Я думаю, что архитектура RESTful побуждает вас разрабатывать приложения без сохранения состояния. Как писал @ 2pence, «каждый HTTP-запрос должен содержать достаточно информации, чтобы получатель мог обработать его, чтобы он полностью соответствовал природе HTTP без сохранения состояния» .

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