Каков наилучший способ использовать HTTP-аутентификацию в Ajax-приложении, которое не на 100% AJAX?
У меня есть стандартная страница входа в систему HTML, которую я бы предпочел использовать вместо стандартного всплывающего окна HTTP-аутентификации, предоставляемого браузерами. Сегодня я использую сеансовые куки для отслеживания сеанса после входа в систему, но я бы хотел, чтобы у вас не было состояния и каждый раз проходил HTTP-аутентификацию. Веб-сервисы, к которым я обращаюсь, уже поддерживают это, так что это проблема только браузера.
Добавление учетных данных для аутентификации в jQuery тривиально, но я не знаю, как их сохранить. Если вы перейдете со страницы входа (jsp) на домашнюю страницу (еще один jsp), вы явно не сохраните поля имени пользователя и пароля на странице входа. Я знаю, что некоторые браузеры будут хранить ваши учетные данные HTTP-аутентификации, если вы введете их из всплывающего окна, но я не знаю, сохранятся ли они при использовании XHRRequest. Если они делают, есть ли большая согласованность между браузерами?
Кроме того, пользователь также должен иметь возможность "выйти" из приложения. Если браузер хранит учетные данные аутентификации, есть ли способ очистить их с помощью JavaScript.
Я чувствую, что не могу быть первым человеком, который попытается решить это. Есть какой-нибудь плагин jQuery или что-то, что уже обрабатывает это? Или просто невозможно сделать то, что я пытаюсь сделать?
5 ответов
Обновить
Ответ ниже был размещен в 2012 году, и ссылки в основном не работают. Однако с тех пор с помощью JSON Web Tokens появился более изящный, основанный на стандартах подход к тому же решению. Вот хороший пост в блоге, объясняющий, как их использовать.
Большинство ответов упускают суть, которая заключается в том, чтобы избежать какого-либо сеанса на стороне сервера. Я не хочу никакого состояния приложения на сервере. Я присуждаю награду за ответ, который был ближе всего, но реальная заслуга принадлежит группе по обсуждению вопросов отдыха и Джону Муру за правильный ответ и Майку Амундсену за помощь в его понимании.
Лучший ответ, который я получил, - это использовать cookie, а не типичный cookie cookie с автоматическим идентификатором сеанса, предоставляемый большинством серверов приложений. Файл cookie (который будет автоматически отправляться при каждом последующем запросе) представляет собой идентификатор пользователя и время, подписанное сервером. Вы можете включить время истечения в файл cookie, чтобы он имитировал типичную 30-минутную сессию на сервере (что означает, что вы должны продвигать его с последующими запросами), а также сохранял бы тот же cookie в течение вечного времени.
Часть XHR/AJAX - красная сельдь. Это будет работать независимо от того, выполняете ли вы запросы XHR или старомодное постраничное веб-приложение. Основными моментами являются:
- Файл cookie автоматически отправляется при последующих запросах, поэтому никаких специальных сценариев не требуется - это просто работа браузеров.
- Серверу не нужно хранить какой-либо сеанс для пользователя, поэтому пользователь может подключиться к любому серверу в кластере и не должен повторно проходить аутентификацию.
Хорошо, я попробую помочь...
Во-первых, понять, как работает HTTP-аутентификация. Существует две версии - Basic и Digest. Основные передачи в виде открытого текста, дайджест зашифрован. При этих типах аутентификации имя пользователя / пароль передаются в заголовке HTTP при каждом отдельном запросе. Браузер захватывает их при входе в систему, и они сохраняются в недоступном файле cookie сеанса браузера, который удаляется при закрытии сеанса браузера. Поэтому, отвечая на один из ваших вопросов, вы не можете получить к ним доступ из javascript.
Вы можете создать свои собственные переменные cookie для имени пользователя и пароля. Функции jQuery для этого действительно просты. Посмотрите модуль jquery-cookie как пример того, как установить сеансовые куки. Они могут быть извлечены из cookie-файла сеанса и отправлены с каждым запросом ajax и проверены на сервере. Тем не менее, это не очень хороший способ выполнить аутентификацию, так как прослушивание сети позволит любому легко получить ваши данные аутентификации. Но это будет работать.
Использование аутентификации на основе файлов cookie сеанса, когда идентификатор сеанса отправляется с каждым запросом, является наилучшим способом сделать это. На стороне сервера у вас должна быть функция, вызываемая для каждого HTTP-запроса. Эта функция должна делать следующее:
check to see if the session has been authenticated
if no:
redirect to login screen
if yes:
do authorization and allow the user access to the page
Большинство веб-фреймворков поддерживают проверку подлинности файлов cookie сеансов и управление идентификаторами сеансов на сервере. Это определенно путь.
У вас есть 2 варианта:
1) Хранение учетных данных на стороне клиента - не очень хорошая идея. По понятным причинам вы не хотите хранить имя пользователя / пароль на клиенте. Если у вас была хешированная версия пароля, она может быть не такой уж плохой, но все же не рекомендуется. В любом случае, если вы собираетесь хранить на клиентской стороне, вам нужно либо использовать cookie-файл, либо локальное хранилище HTML5 (которое пока широко не поддерживается)
2) Хранение учетных данных на стороне сервера - обычно выполняется с помощью сеансов. Затем полученный идентификатор сеанса может быть передан обратно клиенту и сохранен в файле cookie или в URL каждого последующего вызова AJAX (?SESSID=xyz например)
Подход на стороне сервера будет наиболее безопасным, надежным и простым в реализации
Это интересный.
Управляйте пользовательскими сессиями на сервере с помощью файлов cookie. Создайте сеанс, когда пользователь впервые заходит на страницу входа, и передайте идентификатор / ключ сеанса в качестве значения одному из файлов cookie через ответ. Когда пользователь аутентифицирован, поместите информацию "ключа" пользователя в cookie и "значения" в контексте приложения на сервере. После того, как пользователь вошел в систему, любой последующий запрос будет аутентифицирован на основе значения cookie сеанса на сервере. Авторизация будет осуществляться на основе пользовательского "ключа", переданного в качестве значения cookie.
При выходе из системы удалите файлы cookie, основанные на сеансе, с сервера и обновите страницу до страницы по умолчанию
Печенье причудливо с разными браузерами - просто примечание;)
Надеюсь это поможет.
Немного интересен тот факт, что вы рассматриваете возможность передачи некоторых подлинных данных клиенту. Если вы хотите обычное решение, то решение KOGI на стороне сервера - это то, что вам нужно.
Но вы также, похоже, задаете вопросы об утечках памяти, связанных с предоставленными вами секретами. Хорошие вопросы Но для того, чтобы ответить на этот вопрос, я бы сказал, что это должно зависеть от браузера. Это внутренняя часть браузера, внутренняя часть движка javascript - зависит от того, где клиентское приложение (т. Е. Браузер или js в браузере) хранит значения, введенные пользователем.
Скорее всего, эти значения не копируются без необходимости во всей памяти, но нет способа гарантировать это. Помимо ответственной практики кодирования javascript, вы ничего не можете сделать, чтобы гарантировать ограничение расположения пользовательских входов.
Небольшое отступление
Суть в том, что если вы храните его на клиенте, он не является действительно защищенным - если сервер не хранит зашифрованную информацию на клиенте с ключом, который имеет только сервер (или пользователь с их правильными учетными данными). Таким образом, вы могли бы кодировать приложение JS, чтобы сделать некоторую аутентификацию на клиенте - почти так же, как банковская карта (раньше?) Делает аутентификацию POS, проверяя ПИН-код на ПИН-коде на карте, а не обратно в БД. Он основан на (несколько неубедительном) предположении, что пользователь не имеет прямого доступа на чтение / запись к "темной области" cookie / локального хранилища на клиенте / магнитной полосе на банковской карте. Поэтому я бы посоветовал это только в качестве дисквалификатора для ложных аутентификаторов, а не в качестве единственного квалификатора для учетных данных.
Главный пункт
Если вы не хотите сохранять состояние, просто сохраните учетные данные пользователя в локальном хранилище или в виде файла cookie, но зашифруйте их с помощью ключа сервера. Когда они вам понадобятся, отправьте XHR с зашифрованными / использовать сохраненные учетные данные на сервер по протоколу HTTPS, дайте вашему серверу расшифровать их и отправьте обратному вызову. Затем передайте эти открытые тексты HTTPS, чтобы подтвердить свою подлинность.