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

Question

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

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

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

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

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

Answer 1

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

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

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

Было бы плохо иметь ОТДЫХ сервис, скажем, / сеанс, который принимает ПОЛУЧИТЕ запрос, где вы будете проходить в имя пользователя / пароль как часть запрос и возвращает токен сеанса если аутентификация прошла успешно, которые могут быть переданы вместе с последующие запросы? Это делает смысл с точки зрения ОТДЫХА, или что упускает из виду?

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Было бы плохо иметь ОТДЫХ сервис, скажем, / сеанс, который принимает ПОЛУЧИТЕ запрос, где вы будете проходить в имя пользователя / пароль как часть запрос и возвращает токен сеанса если аутентификация прошла успешно, которые могут быть переданы вместе с последующие запросы? Это делает смысл с точки зрения ОТДЫХА, или что упускает из виду?

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

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

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

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

Answer 6

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

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