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

Question

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

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

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

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

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

Answer 1

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

Вместо аутентификации пользователя вы можете подумать о создании сеанса.Вам будет возвращен новый "Идентификатор сеанса" вместе с соответствующим кодом состояния HTTP (200:Хорошо, 403:Запрещено и т.д.).

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

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

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

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

Answer 2

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

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

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

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

Сделай это.

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

Ре:Ответ Дэниела:

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

Не лучше ли создать USER как объект и аутентифицироваться с помощью дайджест-аутентификации (или файла cookie, если необходимо).Таким образом, каждый пользователь получает свой собственный постоянный кеш вместо кеша, который существует один день и исчезает.

Для меня это также имеет более логичный смысл, поскольку вы заставляете страницу выглядеть по-разному в зависимости от ПОЛЬЗОВАТЕЛЯ (добавляя «привет [имя]» и тому подобное), а разница между состояниями «вошел в систему» ​​и «вышел из системы» зависит о том, включен ли пользователь в URL-адрес.Предоставляется ли конкретному человеку доступ к URL-адресу этого пользователя, зависит от того, может ли он аутентифицироваться как этот пользователь.

Answer 7

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

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