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

Например - я вхожу, используя username='rasmus'и password='default'. В таком случае данные будут опубликованы на сервере, который должен проверить и войти в систему, если аутентифицирован. Однако в течение всего процесса сервер также генерирует идентификатор сеанса, который будет сохранен в файле cookie в моем браузере. Теперь сервер также сохраняет этот идентификатор сеанса в своей файловой системе или хранилище данных.

Но основываясь только на идентификаторе сеанса, как он сможет узнать мое имя пользователя во время моего следующего обхода сайта? Хранить ли данные на сервере в качестве Словаря , где ключ будет идентификатор сеанса и деталь , как username, и emailт.д. быть значением?

Я запутался здесь. Нужна помощь.

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

Файлы cookie или параметры URL (например, http://example.com/myPage?asd=lol&boo=no ) являются подходящими способами передачи данных между 2 и более запросами. Однако они не очень хороши, если вы не хотите, чтобы эти данные были доступны для чтения / редактирования на стороне клиента.

Решение состоит в том, чтобы сохранить эту сторону сервера данных, присвоить ей «id» и позволить клиенту только знать (и передавать при каждом http-запросе) этот id. Вот и все, сеансы реализованы. Или вы можете использовать клиент в качестве удобного удаленного хранилища, но вы бы зашифровали данные и сохранили секретный сервер.

Конечно, нужно учитывать и другие аспекты: например, вы не хотите, чтобы люди угоняли сеансы других, вы хотите, чтобы сеансы длились не вечно, а заканчивались, и так далее.

В вашем конкретном примере идентификатор пользователя (может быть именем пользователя или другим уникальным идентификатором в вашей пользовательской базе данных) сохраняется в данных сеанса на стороне сервера после успешной идентификации. Затем для каждого HTTP-запроса, получаемого от клиента, идентификатор сеанса (предоставляемый клиентом) будет указывать на правильные данные сеанса (хранящиеся на сервере), которые содержат идентифицированный идентификатор пользователя - таким образом, ваш код будет знать, какого пользователя он разговаривает с

Простое объяснение по аналогии

Представьте, что вы находитесь в банке, пытаясь получить деньги с вашего счета. Но это темно; банк абсолютно черный: света нет, и ты не можешь видеть свою руку перед своим лицом. Вас окружают еще 20 человек. Они все выглядят одинаково. И у всех одинаковый голос. И каждый потенциальный плохой парень. Другими словами, HTTP не имеет состояния.

Этот банк - забавный тип банка - для примера вот как это работает:

1. вы ждете в очереди (или онлайн) и говорите с кассиром: вы делаете запрос на снятие денег, а затем
2. вам придется ненадолго подождать на диване, а через 20 минут
3. Вы должны пойти и на самом деле забрать свои деньги у кассира.

Но как вам скажет кассир, кроме всех остальных?

Кассир не может видеть или с готовностью узнавать вас, помните, потому что свет погас. Что если ваш кассир даст вам снятие 10000 долларов другому человеку - не тому человеку ?! Абсолютно важно, чтобы кассир узнал вас как того, кто снял деньги, чтобы вы могли получить деньги (или ресурсы), о которых вы просили.

Решение:

Когда вы впервые предстаете перед кассиром, он или она говорит вам что-то в тайне:

«Когда бы вы ни говорили со мной, - говорит кассир, - вы должны сначала идентифицировать себя как GNASHEU329 - таким образом, я знаю, что это вы».

Никто другой не знает секретный пароль.

Пример того, как я снял деньги:

Поэтому я решил пойти и расслабиться в течение 20 минут, а потом я иду к кассиру и говорю: «Я хотел бы забрать мой вывод»

Кассир спрашивает меня: "Кто ты такой ??!"

"Это я, мистер Джордж Бэнкс!"

"Докажите это!"

И тогда я говорю им мой код доступа: GNASHEU329

"Конечно, мистер Бэнкс!"

Это в основном то, как работает сессия. Это позволяет однозначно идентифицировать себя в море миллионов людей. Вы должны идентифицировать себя каждый раз, когда вы имеете дело с кассиром.

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

Объяснение через картинки:

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

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

Некоторые переменные сеанса передаются как заголовки HTTP . Они передаются туда-сюда за кулисами просмотра каждой страницы, поэтому они не отображаются в браузере и не говорят всем о том, что может быть приватным. Среди них USER_AGENT или тип браузера, запрашивающего страницу, REFERRER или страница, которая ссылается на запрашиваемую страницу, и т. Д. Некоторое программное обеспечение веб-сервера добавляет свои собственные заголовки или передает дополнительные данные сеанса, относящиеся к серверному программному обеспечению. Но стандартные довольно хорошо документированы.

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

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

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

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

Думайте о HTTP как о человеке (A), который имеет КРАТКОСРОЧНУЮ ПОТЕРЮ ПАМЯТИ и забывает каждого человека, как только тот человек исчезает из поля зрения.

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

То же самое с HTTP. Это страдает от краткосрочной потери памяти. Он использует сеансы для записи всего, что вы делали во время использования веб-сайта, а затем, когда вы приходите снова, он идентифицирует вас с помощью файлов cookie (cookie - это как токен). Изображение - это Сессия здесь, а ID - это Cookie здесь.