Какой метод аутентификации пользователей веб-страницы является предпочтительным для RESTful?

Question

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

Я установил и запустил систему, строго используя URL-адреса, чтобы определить «существительные» в системе и извлечь «глаголы» из методов HTTP-запроса. Я использую javascript-вызовы ajax для предоставления доступа к методам DELETE и PUT, которые не могут предоставить формы HTML. (Я понимаю, что эти меры не обязательно должны быть RESTful, но они удовлетворяют требованию «Единого интерфейса»).

Проблема связана с отсутствием состояния и кэшируемостью при аутентификации. Стандартная модель для аутентификации пользователей на веб-сайтах включает в себя событие аутентификации «логин», после которого (в случае успеха) пользователь «находится внутри стены» с постоянным безопасным сеансом и может видеть и выполнять действия по последующим запросам, которые не прошедшие проверку подлинности пользователи не могут. Такое постоянство аутентификации нарушает RESTful-ность. Кэширование и отсутствие состояния кажутся нарушенными, потому что аутентифицированный пользователь, вероятно, увидит HTML, который отличается от того, который не аутентифицированный пользователь увидит для того же запроса (например, на боковой панели для зарегистрированного пользователя может быть форма входа в систему). наш пользователь).

Использование стратегий www-authenticate для аутентификации пользователя только по запросам, требующим аутентификации, представляется шагом в правильном направлении, поскольку в нем нет концепции постоянного безопасного сеанса. Однако все еще остается вопрос о том, как изобразить «зарегистрированный» внешний вид для конечного пользователя в соответствии с тем, что мы все привыкли ожидать от веб-сайтов.

Итак, как вы думаете, какой предпочтительный способ обрабатывать аутентификацию и разрешение веб-страницы строго RESTful-способом, при этом оставляя возможность входить в декорации в HTML?

Answer 1

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

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

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

Дайджест-проверка подлинности - учетные данные для каждого запроса - полностью RESTful.

Сделай это.

Чтобы упростить задачу, вы можете вычислить дайджест-аутентификацию Nonce на основе времени, чтобы он работал в течение некоторого периода времени (6 минут, 0,1 часа - это хорошо). Каждые несколько минут запрос отправляет статус 401 и требует пересчета дайджеста.

Answer 2

Это постоянство аутентификации кажется, нарушает RESTful-ness

Вместо аутентификации пользователя вы можете подумать о создании сеанса. Вам будет возвращен новый «ID сеанса» вместе с соответствующим кодом статуса HTTP (200: ОК, 403: Запрещено и т. Д.).

Пользователь, вероятно, увидит HTML, который отличается от того, что не прошедший проверку пользователь увидит тот же запрос

Вы будете спрашивать свой REST-сервер: «Можете ли вы ПОЛУЧИТЬ мне HTML (или любой ресурс) для этого идентификатора сеанса?». HTML будет отличаться в зависимости от «идентификатора сессии».

В этом методе нет стены для "постоянных безопасных сеансов". Вы просто действуете на сессии.

Существительное (или ресурс) будет представлять фактический сеанс, если вы выберете этот метод.

Answer 3

Одним из вариантов сохранения кэшируемости в посредниках для страниц с пользовательскими элементами является добавление пользовательской разметки через Ajax. Каждый пользователь использует одну и ту же страницу, включая некоторый JavaScript, который выполняет XHR-запрос к ресурсу, который возвращает что-то другое в зависимости от имени пользователя. Затем вы объединяете это со страницей на стороне клиента. Большая часть страницы будет затем кэшироваться, так как она одинакова для каждого пользователя.

Другим вариантом является использование ESI (Edge Side Includes). С их помощью сам кеш может объединять различные представления для получения конечного результата.

Answer 4

Re: Даниил ответ:

Если сеанс является временным объектом, который быстро удаляется, это не очень кэшируется, так как любой созданный вами кеш будет иметь только полезное время жизни, может быть, один день, но в любом случае продолжит использовать пространство в кеше.

Не лучше ли создать ПОЛЬЗОВАТЕЛЯ как объект и выполнить аутентификацию с использованием дайджест-аутентификации (или файла cookie, если необходимо). таким образом, каждый пользователь получает свой собственный постоянный кеш вместо кеша, который длится один день и исчезает.

Это также имеет для меня более логичный смысл, так как вы заставляете страницу выглядеть по-разному в зависимости от пользователя (добавление «hello [name]» и т. Д.) И разницы между «авторизованными» и «вышедшими из системы». "Состояния зависит от того, включен ли пользователь в URL. Будет ли определенному человеку предоставлен доступ к этому конкретному URL-адресу пользователя, зависит от того, могут ли они пройти аутентификацию в качестве этого пользователя.

Answer 5

"Такое постоянство аутентификации, по-видимому, нарушает RESTful-ness. Кеширование и отсутствие состояния, по-видимому, нарушены, поскольку аутентифицированный пользователь, вероятно, увидит HTML, который отличается от того, который не прошедший аутентификацию пользователь увидит для того же запроса"

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

Answer 6

Я думаю об этом так: «имя существительное» в аутентификации пользователя - это сеанс. Таким образом, ваша форма входа в систему использует запрос POST для «создания» нового сеанса, а выход из системы использует запрос DELETE для «удаления» сеанса.

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

Answer 7

Если ваша платформа RESTful будет использоваться только вашим веб-приложением и не будет использоваться в качестве API для третьих сторон, я не вижу причин, по которым вы не можете использовать ту же схему аутентификации, что и остальная часть вашего приложения.Вы можете думать об этой аутентификации как о более низком уровне, чем уровень «приложения».Уровень приложения все еще может оставаться без состояния чистым способом RESTful.

Конечно, если вы планируете создать веб-API RESTful, вам нужно подумать об этом.