Каков наилучший способ использовать HTTP-аутентификацию в приложении Ajax, которое не на 100% AJAX?

Question

У меня есть стандартная HTML-страница входа в систему, которую я бы предпочел использовать вместо стандартного всплывающего окна HTTP-аутентификации, предоставляемого браузерами.Сегодня я использую сеансовые куки для отслеживания сеанса после входа в систему, но я бы хотел, чтобы у вас не было состояния и каждый раз проходил HTTP-аутентификацию.Веб-сервисы, к которым я обращаюсь, уже поддерживают это, так что это проблема только браузера.

Добавление учетных данных для аутентификации тривиально в jQuery, но я не знаю, как их сохранить.Если вы перейдете со страницы входа (jsp) на домашнюю страницу (еще один jsp), вы явно не сохраните поля имени пользователя и пароля на странице входа.Я знаю, что некоторые браузеры будут хранить ваши учетные данные HTTP-аутентификации, если вы введете их из всплывающего окна, но я не знаю, сохранятся ли они при использовании XHRRequest.Если это так, есть ли большая согласованность между браузерами?

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

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

Answer 1

У вас есть 2 варианта:

1) Хранение учетных данных на стороне клиента - не очень хорошая идея. По понятным причинам вы не хотите хранить имя пользователя / пароль на клиенте. Если у вас была хешированная версия пароля, она может быть не такой уж плохой, но все же не рекомендуется. В любом случае, если вы собираетесь хранить на стороне клиента, вы должны либо использовать cookie-файл, либо локальное хранилище HTML5 (что пока не поддерживается широко)

2) Хранение учетных данных на стороне сервера - обычно выполняется с сеансами. Затем полученный идентификатор сеанса может быть передан обратно клиенту и сохранен в файле cookie или в URL-адресе каждого последующего вызова AJAX (например, ?SESSID=xyz)

Подход на стороне сервера будет наиболее безопасным, надежным и простым в реализации

Answer 2

Хорошо, я попробую помочь ...

Во-первых, поймите, как работает 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 сеансов и управление идентификаторами сеансов на сервере. Это, безусловно, путь.

Answer 3

Это интересный.

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

При выходе очистите сеансовые файлы cookie с сервера и обновите сайт до страницы по умолчанию.

Печенье странное в разных браузерах - просто заметка;)

Надеюсь, это поможет.

Answer 4

Обновление

Ответ ниже был опубликован в 2012 году, и ссылки в основном не работают.Однако с тех пор более изящный, основанный на стандартах подход к тому же решению появился с использованием JSON Web Tokens .Вот хорошее сообщение в блоге , объясняющее, как их использовать.

---

В большинстве ответов пропущен смысл: избегать сеансов на стороне сервера.Я не хочу никакого состояния приложения на сервере.Я назначу награду за ответ, который был ближе всего, но реальная заслуга принадлежит группе по обсуждению отдыха и Джону Муру за правильный ответ и Майку Амундсену1015 * за то, что помог мне понять это на самом деле.

Лучший ответ, который я получил, - использовать cookie, а не типичный cookie cookie с автоматическим идентификатором сеанса, предоставляемый вам большинством серверов приложений.Файл cookie (который будет автоматически отправляться при каждом последующем запросе) представляет собой идентификатор пользователя и время, подписанное сервером.Вы можете включить в файл cookie время истечения срока действия, чтобы он имитировал типичную 30-минутную сессию на сервере (что означает, что вы должны продвигать его с последующими запросами), а также сохранял этот файл cookie в силе всегда.

Часть XHR / AJAX - красная сельдь.Это будет работать независимо от того, выполняете ли вы запросы XHR или старомодное постраничное веб-приложение.Основные моменты:

• Файл cookie автоматически отправляется при последующих запросах, поэтому никаких специальных сценариев не требуется - это просто работа браузеров.
• Серверу не нужно хранить какой-либо сеанс для пользователя, поэтому пользователь может подключиться к любому серверу в кластере и не должен повторно проходить аутентификацию.

Answer 5

Немного интересен тот факт, что вы рассматриваете возможность передачи некоторых подлинных данных клиенту.Если вы хотите обычное решение, то предложение KOGI на стороне сервера - это то, что вам нужно.

Но вы также, похоже, задаете вопросы об утечках памяти, связанных с предоставленными вами секретами.Хорошие вопросыНо для того, чтобы ответить на этот вопрос, я бы сказал, что это должно зависеть от браузера.Это внутренняя часть браузера, внутренняя часть движка javascript - зависит от того, где клиентское приложение (т. Е. Браузер или js в браузере) хранит значения, введенные пользователем.

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

Небольшое отступление

Суть в том, что если вы сохраните егона клиенте это не очень безопасно - если только сервер не хранит зашифрованную информацию на клиенте с ключом, который имеет только сервер (или пользователь с их правильными учетными данными).Таким образом, вы могли бы написать код приложения JS для аутентификации на клиенте - во многом аналогично тому, как банковская карта (раньше?) Делала аутентификацию POS, проверяя ПИН-код на ПИН-коде на карте, а не обратно в БД.Он основан на (несколько неубедительном) предположении, что пользователь не имеет прямого доступа на чтение / запись к «темной области» cookie / локального хранилища на клиенте / магнитной полосе на банковской карте.Поэтому я бы посоветовал это только в качестве дисквалификатора для ложных аутентификаторов, а не в качестве единственного квалификатора для учетных данных.

Основная точка

Если вы не хотите сохранять состояние, просто сохраните учетные данные пользователя в локальном хранилище или в виде файла cookie, но зашифруйте их с помощью ключа сервера.Когда они вам понадобятся, отправьте XHR с зашифрованными / использовать сохраненные учетные данные на сервер по протоколу HTTPS, дайте вашему серверу расшифровать их и отправьте обратному вызову.Затем передайте открытый текст HTTPS, чтобы подтвердить свою подлинность.