Привет уже писал это наблюдение и вопрос на этот вопрос ранее, но только позже заметил, что это был старый и "мертвый" вопрос. Поскольку мне действительно нравятся некоторые идеи от других, я переписываю это как новый вопрос.
К вопросу о том, как сделать аутентификацию RESTfully, люди обычно энтузиастски кричат "HTTP Authentication". Тем не менее, я сомневаюсь, что эти люди когда-либо пытались сделать приложение на основе браузера (вместо веб-службы "машина-машина" ) с помощью REST. (без обид - я просто не думаю, что они когда-либо сталкивались с осложнениями)
Проблемы, которые я обнаружил при использовании HTTP-аутентификации в службах RESTful, которые создают HTML-страницы для просмотра в браузере, следующие:
- Пользователь
- обычно получает уродливое окно входа в браузер, которое является недружелюбным пользователем. вы не можете добавить поиск пароля, окна справки и т.д.
- выход из системы или вход в систему под другим именем - проблема - браузеры будут отправлять отправку информации об аутентификации на сайт до закрытия окна
- Тайм-ауты трудны.
Очень проницательная статья, которая решает эти точки за точкой, здесь, но это приводит к большому количеству хакеров, зависящих от браузера, обходным решениям к обходным методам и т.д. Таким образом, он также не является совместимым с передовым способом, поэтому требуется постоянное обслуживание при выпуске новых браузеров. Я не считаю это чистым и понятным дизайном, плюс я чувствую, что для меня много лишней работы и головной боли, чтобы я мог с энтузиазмом показывать свой значок REST своим друзьям.
Я считаю, что файлы cookie - это решение. Но подождите, печенье злые, не так ли? Нет, это не так, как часто используются куки, это зло. Сам файл cookie - это всего лишь часть клиентской информации, точно так же, как информация об аутентификации HTTP, которую браузер будет отслеживать во время просмотра. И эта часть клиентской информации отправляется на сервер по каждому запросу, опять же, как и HTTP-аутентификация. Понятно, что единственное отличие состоит в том, что содержимое этой части клиентского состояния может быть определено сервером как часть его ответа.
Сделав сеансы ресурсом RESTful с помощью только следующих правил:
- Сессия отображает ключ к идентификатору пользователя (и, возможно, метку времени последнего действия для тайм-аутов).
- Если сеанс существует, это означает, что ключ действителен.
- Вход означает POSTing to/sessions, новый ключ устанавливается как файл cookie
- Выход из системы означает DELETEING/session/{key} (с перегруженным POST, помните, что мы - браузер, а HTML 5 - еще длинный путь)
- Аутентификация выполняется путем отправки ключа в виде файла cookie при каждом запросе и проверки наличия и действительности сеанса
Единственное отличие от HTTP-аутентификации заключается в том, что ключ аутентификации генерируется сервером и отправляется клиенту, который продолжает его отправлять, вместо того, чтобы клиент его вычислял из введенных учетных данных.
Я считаю, что это достаточное решение, которое прекрасно работает, но я должен признать, что мне недостаточно эксперта по безопасности, чтобы определить потенциальные дыры в этой схеме. Все, что я знаю, это то, что используют сотни не-RESTful веб-приложений по существу тот же протокол входа ($ _SESSION inphp, HttpSession в j2ee и т.д.). Содержимое заголовка файла cookie просто используется для адресации ресурса на стороне сервера, так же как язык принятия может использоваться для доступа к ресурсам перевода и т.д. Я чувствую, что это то же самое, но, может быть, другие нет? Как вы думаете, ребята?
