Почему аутентификация на основе форм не рассматривается RESTful?

Хотя я "думаю", я понимаю, мне нужна определенная ясность. С PURE Restful аутентификацией все становится немного громоздким, и использование форм помогает с интерфейсом пользовательского интерфейса (т.е. Получить отдельную страницу входа в систему, ссылки на забытые пароли, более простой выход из системы и т.д.).

Теперь появляются Формы, и некоторые люди говорят "не успокаивающе" - что "не успокаивает" о них? Разве это так, что нет соответствующего ресурса входа? Или это заставляет что-то еще, что мне не хватает?

Примечание. Если они создают сеансы с ними, это совсем другое дело. Я больше заинтересован в том, чтобы знать, "почему" они заклеймены как спокойные? Просто поиск по Google для "Проверка подлинности на основе форм-фактуры против спокойной проверки подлинности" вызывает несколько хитов.

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

Ответ 1

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

Сессии - это состояние сервера, что нарушает ограничение без сохранения состояния архитектуры REST.

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

Если вы включите их в полезную нагрузку, вы можете включить их в тело, но только для POST или PUT, а не для GET или DELETE (поскольку у них нет тел).

Если вы включите их в URL как часть параметров запроса, URL-адрес больше не обязательно будет представлять фактический ресурс. Один из других принципов состоит в том, что URL-адрес соответствует ресурсу. Добавление внеполосной информации (например, учетных данных) в пределах параметров запроса muddies, которые ограничивают бит.

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

Ответ 2

Отличный вопрос. Я думаю, что пуристы RESTful, скорее всего, скажут, что наличие URI, связанного с действием, а не с ресурсом, является тем, что делает auth не RESTful, что вы указали сами.

Честно говоря, я думаю, что идея 100% чистого RESTful-приложения - это скорее утопический идеал, когда дело касается веб-приложений. Я считаю, что это возможно для веб-служб RESTful, поскольку вызывающие приложения могут передавать учетные данные с заголовком запроса.

В конце дня я думаю, что до тех пор, пока ваше приложение работает, все в порядке, и вам не следует беспокоиться о том, чисто ли он RESTful.

Что мои $0,02.

Ответ 3

Из этого ответа:

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

Это не то, что основанный на форме auth не RESTful — это не RESTful, чтобы иметь сеанс вообще. Способ RESTful заключается в отправке учетных данных с каждым запросом. Это можно было бы легко подслушать, но HTTPS/SSL/TLS закрывает это отверстие.

Ответ 4

Аутентификация на основе форм не использует методы аутентификации, встроенные в HTTP (например, базовая аутентификация, аутентификация дайджеста).

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