Каков предпочтительный метод для аутентификации пользователей веб-страницы УСПОКОИТЕЛЬНЫМ способом?
Я разрабатываю новую экспериментальную платформу веб-приложений, и я решил дать УСПОКОИТЕЛЬНЫЙ некоторое внимание. Я читал на основах и чувствую, что у меня есть довольно хорошее понимание УСПОКОИТЕЛЬНЫХ как понятие.
У меня есть система и выполнение, с помощью URL строго, чтобы определить 'существительные' в системе и взять 'глаголы' из методов Запроса HTTP. Я использую JavaScript ajax, звонит, чтобы обеспечить доступ к УДАЛЕНИЮ и ПОМЕСТИТЬ методы, которые не могут предоставить HTML-формы. (Я понимаю, что эти меры строго не требуются, чтобы быть УСПОКОИТЕЛЬНЫМИ, но это удовлетворяет 'Универсальное Интерфейсное' требование).
Проблема идет с отсутствием гражданства и cacheability с аутентификацией. Стандартная модель для аутентификации пользователя на веб-сайтах включает событие аутентификации "входа в систему", после которого (если успешный) пользователь "в стене" с персистентной безопасной сессией и может видеть и сделать вещи по последующим запросам, какие неаутентифицируемые пользователи не могут. Эта персистентность аутентификации, кажется, повреждает УСПОКОИТЕЛЬНОСТЬ. Кэширование и отсутствие гражданства, кажется, повреждается, потому что аутентифицируемый пользователь будет, вероятно, видеть HTML, который отличается от этого, которое неаутентифицируемый пользователь будет видеть тот же запрос (например, могла бы быть форма входа в систему на боковой панели для вышедшего из системы пользователя).
Используя www-аутентифицируют стратегии аутентифицировать пользователя только по запросам, которые требуют, чтобы аутентификация, казалось, была шагом в правильном направлении, поскольку это не включает понятие персистентной безопасной сессии. Однако существует все еще вопрос того, как изобразить "зарегистрированное" появление конечному пользователю в соответствии с тем, что мы все приехали для ожидания из веб-сайтов.
Таким образом в существующих взглядах, что предпочтительный путь состоит в том, чтобы обработать аутентификацию и управление правами веб-страницы СТРОГО УСПОКОИТЕЛЬНЫМ способом при тихом обеспечении, вошел в систему художественные оформления в HTML?
7 ответов
Эта стойкость аутентификации Кажется, что это нарушает RESTful-ness
Вместо того, чтобы аутентифицировать пользователя, вы можете подумать о создании сеанса. Вам будет возвращен новый "Идентификатор сессии" вместе с соответствующим кодом статуса HTTP (200: OK, 403: Forbidden и т.д.)
Пользователь, вероятно, увидит HTML, который представляет собой отличный от того, который неавторизованный пользователь увидит для тот же самый запрос
Вы будете запрашивать ваш REST сервер: "Можете ли вы предоставить мне HTML (или любой другой ресурс) для этого идентификатора сессии?". HTML будет отличаться в зависимости от "идентификатора сессии".
С помощью этого метода нет стены для "постоянных защищенных сессий". Вы просто действуете по сеансу.
Существительное (или ресурс) будет представлять реальный сеанс, если вы выберете этот метод.
."Стандартная модель для аутентификации пользователей на веб-сайтах включает в себя событие аутентификации "входа", после которого (в случае успеха) пользователь находится "внутри стены" с постоянным защищенным сеансом"
Это не совсем верно. Частично это так, но только для веб-сайтов, которые изобретают свою собственную аутентификацию.
Если вы используете "дайджестовую аутентификацию", браузер должен посылать учетные данные с каждым запросом.
Дайджестовая аутентификация - учетные данные с каждым запросом - полностью RESTful.
Сделайте это.
Для того, чтобы немного упростить процесс, вы можете вычислить дайджестовую аутентификацию Nonce по времени, чтобы она была хороша в течение некоторого периода времени (6 минут, 0.1 часа - хорошо). Каждые несколько минут запрос посылает статус 401 и требует пересчета дайджеста
.Я думаю об этом вот так: Существительное" в аутентификации пользователя - это сеанс. Поэтому ваша форма входа использует POST запрос для "создания" нового сеанса, а выход из системы использует DELETE запрос для "удаления" сеанса.
Я знаю, что вы имеете в виду, говоря о постоянстве аутентификации, идущем против RESTfulness, но cookies (которые создают иллюзию постоянства) просто являются частью каждого запроса.
.Если ваш RESTful фреймворк будет использоваться только вашим веб-приложением и не будет использоваться в качестве API для третьих лиц, я не вижу причин, по которым вы не можете использовать ту же самую схему аутентификации, что и остальное ваше приложение. Вы можете думать об этой схеме аутентификации как о более низком уровне, чем уровень "приложения". Уровень приложения все еще может оставаться бездействующим в чистом RESTful способе.
Конечно, если вы планируете создать RESTful web API, вам нужно подумать над этим.
.] "Такое постоянство аутентификации, похоже, нарушает RESTful-ness". Кэширование и безгражданство, похоже, нарушено, потому что аутентифицированный пользователь, вероятно, увидит HTML, который отличается от того, что увидит неаутентифицированный пользователь при одном и том же запросе"[
] []Ничего страшного, если представление ресурса несколько отличается в зависимости от информации об аутентификации. Информация auth является частью сообщения, и поэтому сообщение все еще является "самоописанием". Концептуально вы все еще имеете доступ к тому же самому ресурсу, а ссылки на редактирование и удаление являются разрешенными переходами, а не дополнительными фрагментами данных. Контроль за тем, какие переходы доступны, в зависимости от того, кто обращается к ресурсу, кажется мне правильным[
].Одним из вариантов сохранения кэшируемости в посредниках для страниц с пользовательскими элементами является добавление пользовательской разметки через Ajax. Вы обслуживаете каждое использование одной и той же страницы, включая JavaScript, который будет делать XHR-запрос к ресурсу, который возвращает что-то другое в зависимости от логина пользователя. Затем вы объединяете это со страницей на стороне клиента. Большая часть страницы затем будет кэшируемой, так как она одинакова для каждого пользователя.
Другой возможностью является использование ESI (Edge Side Includes). С их помощью сам кэш может объединять различные представления для построения конечного результата.
Re: Ответ Даниила:
Если сессия - это преходящий объект, который быстро удаляется, это не очень подходит для кэширования, так как любой созданный вами кэш будет иметь полезное время жизни, возможно, всего один день, но в любом случае будет продолжать использовать место в кэше.
Не лучше ли создать USER как объект, и аутентифицировать его с помощью аутентификации digest (или cookie, если нужно). Таким образом, каждый пользователь получит свой собственный постоянный кэш, а не кэш, который проработает день и исчезнет.
Это также имеет более логичный смысл, поскольку вы заставляете страницу выглядеть по-разному в зависимости от пользователя (добавляя 'hello [name]' и т.п.), а разница между состояниями "вошел в систему" и "вышел из системы" зависит от того, включен ли пользователь в URL. Предоставлен ли определенному лицу доступ к URL-адресу конкретного пользователя, зависит от того, может ли он аутентифицироваться как этот пользователь.