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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Решение:

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

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

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

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

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

Кассир спрашивает меня:« Кто вы?! »

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

« Докажите это! »

И затем я сообщаю им свой код доступа: GNASHEU329

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

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

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

Объяснение черезИзображения:

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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