Что такое сеансы? Как они работают?

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Этот банк является забавным типом банка - ради аргумента здесь, как все работает:

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

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

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

Решение:

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

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

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

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

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

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

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

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

И тогда я сообщаю им свой пароль: GNASHEU329

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

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

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

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

Sessions explained via Picture

Ответ 3

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

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

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

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

Ответ 4

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

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

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

Ответ 5

Подумайте о HTTP как о человеке (A), у которого есть УБЫТКА SHORT TERM MEMORY LOSS и забывает о каждом человеке, как только этот человек уходит с поля зрения.

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

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