RESTful-аутентификация

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

самый легкий способ приблизиться к этому путем запуска со встроенных механизмов аутентификации HTTP в RFC 2617 .

Отвечать на этот вопрос от моего понимания...

система аутентификации, которая использует REST так, чтобы Вы не должны были на самом деле отслеживать или управлять пользователями в своей системе. Это сделано при помощи POST методов HTTP, ПОЛУЧИТЕ, ПОМЕСТИТЕ, УДАЛИТЕ. Мы берем эти 4 метода и думаем о них с точки зрения взаимодействия базы данных, как СОЗДАЮТ, СЧИТАЙТЕ, ОБНОВИТЕ, УДАЛИТЕ (но в сети мы используем POST и ПОЛУЧАЕМ потому что, именно это теги привязки в настоящее время поддерживают). Так обработка POST и ДОБИРАЕТСЯ как наш СОЗДАВАЛА/ЧИТАЛА/ОБНОВЛЯЛА/УДАЛЯЛА (CRUD) тогда, мы можем разработать маршруты в нашем веб-приложении, которое будет в состоянии вывести, какого действия CRUD мы достигаем.

, Например, в приложении Ruby on Rails мы можем создать наше веб-приложение, таким образом, что, если пользователь, который зарегистрирован, посещает http://store.com/account/logout тогда, ПОЛУЧАТЬ той страницы может просматриваемый как пользователь, пытающийся выходить из системы. В нашем контроллере направляющих мы создали бы действие в этом, регистрирует пользователя и передает их обратно домашней странице.

А Добираются на странице входа в систему, привел бы к форме. POST на странице входа в систему был бы просмотрен как вход в систему, делают попытку и берут данные POST и используют его для входа в систему.

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

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

Я думаю, что успокоительная аутентификация включает передачу аутентификационного маркера в качестве параметра в запросе. Примерами является использование apikeys API. Я не верю использованию cookie, или http автор квалифицирует.

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

Я обнаружил проблемы с использованием HTTP-аутентификации в службах RESTful, которые создают HTML-страницы для можно просмотреть в браузере:

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

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

Я считаю, что файлы cookie - это решение. Но подождите, печенье - это зло, не так ли? Нет, это не так, то, как часто используются файлы cookie, - зло. Сам файл cookie - это просто часть информации на стороне клиента, точно так же, как информация аутентификации HTTP, которую браузер будет отслеживать во время просмотра. И эта часть информации на стороне клиента отправляется на сервер при каждом запросе, опять же, как и информация HTTP-аутентификации. Концептуально, единственное различие состоит в том, что контент этой части состояния на стороне клиента может быть определен сервером как часть его ответа.

Сделав сеансы ресурсом RESTful со следующими правилами:

• Сеанс сопоставляет ключ с идентификатором пользователя (и, возможно, с отметкой времени последнего действия для тайм-аутов)
• Если существует сеанс , тогда это означает, что ключ действителен.
• Вход означает POSTing to / sessions, новый ключ устанавливается как файл cookie
• Выход из системы означает УДАЛЕНИЕ / sessions / {key} (помните, что с перегруженным POST мы являемся браузером, а HTML 5 - это еще долгий путь)
• Аутентификация выполняется путем отправки ключа в виде файла cookie при каждом запросе и проверки того, существует ли сеанс и является ли он действительным

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

converter42 добавляет, что при использовании https (что нам следует) важно, чтобы для файла cookie был установлен флаг безопасности, чтобы информация для аутентификации никогда не отправлялась через небезопасное соединение. Отличный момент, сам не видел.

Я считаю, что это достаточное решение, которое отлично работает, но должен признать, что ' m недостаточно эксперта по безопасности, чтобы определить потенциальные дыры в этой схеме - все, что я знаю, это то, что сотни не-RESTful веб-приложений используют по существу один и тот же протокол входа в систему ($ _SESSION в PHP, HttpSession в Java EE и т. д.). Содержимое заголовка cookie просто используется для адресации ресурса на стороне сервера, точно так же, как язык принятия может использоваться для доступа к ресурсам перевода и т. Д. Я чувствую, что это то же самое, но, может быть, другие нет? Как вы думаете, ребята?

и так далее. Я чувствую, что это то же самое, но, может быть, другие нет? Как вы думаете, ребята?

и так далее. Я чувствую, что это то же самое, но, может быть, другие нет? Как вы думаете, ребята?