Как работает проверка подлинности на основе файлов cookie?

Ответ 1

Файл cookie - это просто элемент в словаре. Каждый элемент имеет ключ и значение. Для аутентификации ключ может быть чем-то вроде "username", а значением будет имя пользователя. Каждый раз, когда вы делаете запрос на веб-сайт, ваш браузер будет включать файлы cookie в запрос, а хост-сервер проверяет файлы cookie. Таким образом, аутентификация может выполняться автоматически.

Чтобы установить файл cookie, просто добавьте его в ответ, который сервер отправляет после запросов. Затем браузер добавит файл cookie после получения ответа.

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

Браузер сохранит файлы cookie, установленные сервером. В HTTP-заголовке каждого запроса, который браузер делает на этом сервере, он будет добавлять файлы cookie. Он будет добавлять только файлы cookie для доменов, которые их устанавливают. Example.com может установить cookie, а также добавить параметры в HTTP-заголовке, чтобы браузеры отправляли cookie обратно в субдомены, например sub.example.com. Было бы неприемлемо, чтобы браузер когда-либо отправлял файлы cookie в другой домен.

Ответ 2

Я понимаю, что это много лет спустя, но я подумал, что могу расширить ответ на Conor и добавить немного больше к обсуждению.

Может кто-нибудь дать мне пошаговое описание того, как работает проверка подлинности на основе файлов cookie? Я никогда не делал ничего, включая аутентификацию или файлы cookie. Что должен делать браузер? Что должен делать сервер? В каком порядке? Как мы сохраняем безопасность?

Шаг 1: Клиент > Подписание

Прежде чем что-либо еще, пользователь должен зарегистрироваться. Клиент отправляет HTTP-запрос на сервер, содержащий его/ее имя пользователя и пароль.

Шаг 2: Сервеp > Обработка регистрации

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

Шаг 3: Клиент > Вход пользователя

Теперь ваш пользователь входит в систему. Он/она предоставляет свое имя пользователя/пароль, и снова это отправляется как HTTP-запрос на сервер.

Шаг 4: Сервеp > Проверка входа

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

Шаг 5: Сервеp > Создание токена доступа

Если все будет проверено, мы создадим токен доступа, который однозначно идентифицирует сеанс пользователя. Еще на сервере мы делаем две вещи с токеном доступа:

• Сохраните его в базе данных, связанной с этим пользователем.
• Прикрепите его к файлу ответов, который будет возвращен клиенту. Обязательно установите дату/время истечения срока, чтобы ограничить сеанс пользователя.

В дальнейшем cookie будет прикрепляться к каждому запросу (и ответу), сделанному между клиентом и сервером.

Шаг 6: Клиент > Выполнение запросов страницы

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

Это должно помочь вам начать. Обязательно очистите файлы cookie при выходе из системы!