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


333

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

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

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

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


9
«Сохраняет ли он данные на сервере в качестве указания, где ключом будет идентификатор сеанса, а значения, такие как имя пользователя, адрес электронной почты и т. Д., Будут значениями?» ...да. 'Dict' может быть реляционной базой данных, но в основном это так.
bobince

14
Я тоже хотел понимать веб-сессии, теперь я понимаю. Я закончил тем, что написал свою собственную вики, если это помогло: machinesaredigging.com/2013/10/29/how-does-a-web-session-work
eloone

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

1
Я написал свой собственный, используя детали уровня протокола - bitspedia.com/2012/05/…
Асиф Шахзад,

Ответы:


400

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

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

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

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

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


3
msgstr "вы не хотите, чтобы эти данные поддерживались на стороне клиента". Почему нет? Если вы используете надежную криптографию, вы можете позволить клиенту хранить данные сеанса в зашифрованном виде и сохранять их в файле cookie. Это значительно упрощает масштабирование до нескольких узлов, поскольку серверам не нужно ничего «запоминать».
Мэтт Харрисон

5
@MattHarrison, как бы вы расшифровали данные, не «ничего помня» на стороне сервера? Я попытался расширить эту тему в моем ответе так или иначе.
Luke404

2
@MattHarrison помните, что хранение большого количества данных на стороне пользователя увеличит ваш трафик.
Ницас

5
Разве третья сторона не сможет действовать как пользователь, если она сможет перехватить сеансовый ключ пользователя? Предполагая, что сайт не использует HTTPS, кажется, что третье лицо может маскироваться под пользователя с ключом сеанса, даже если ключ зашифрован. Сервер просто расшифрует его.
user137717

2
@ user137717 да, это возможно, если вы разрешаете доступ к сеансу буквально «каждому, который представляет правильный идентификатор сеанса». Существует ряд ограничений, которые вы можете установить. Одним из самых простых и распространенных является сохранение IP-адреса клиента в сеансе: если клиент с другого ip представляет тот же идентификатор сеанса, вы помечаете его как поддельный и удаляете сеанс.
Luke404

110

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

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

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

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

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

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

Решение:

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

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

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

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

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

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

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

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

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

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

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

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

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

Сессии объяснены через изображение


9
Любите это объяснение - в вашей аналогии, как бы вы предотвратили подслушивание других людей, а также прослушивание секретного пароля, который вам говорит кассир? Другими словами, если session_id украден, не сможет ли кто-нибудь имитировать ваши учетные данные?
wmock

угон сеанса @wmock, безусловно, является проблемой: проверьте это! owasp.org/index.php/Session_hijacking_attack
BKSpurgeon

2
прекрасный пример !! это должно быть передано нетерпеливым умам, ищущим обучение!
Виктор

по вашей аналогии, GNASHEU329это пароль пользователя, который генерирует токен аутентификации, срок действия которого истекает до определенного времени; Затем мистер Бэнкс может использовать токен авторизации, чтобы сделать несколько последовательных операций снятия средств без необходимости многократно сообщать кассиру свой пароль?
Даниэль Лизик

@DanielLizik ты защитник. понимание концепции! Но я недостаточно осведомлен о рабочих процессах на основе токенов, чтобы дать вам разумный ответ. Общий принцип заключается в том, что сервер должен быть в состоянии каким-то образом определить, кто является лицом, делающим запрос.
BKSpurgeon

39

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

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

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

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


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

Что означает здесь REFERRER?
Габ 是 好人

@Gab 是 好人 REFERRER обычно означает произвольную строку, которую клиент отправляет в заголовке HTTP-запроса «Referer». Он должен содержать URL ресурса, который, как вы знаете, направил клиента к текущему ресурсу.
Luke404

Спасибо, должно , так что не обязательно. поэтому я думаю, что люди часто используют этот заголовок с семантикой, отличной от предложенной в RFC, верно?
Габ 是 好人

Сначала ты написал, Like cookies, this usually doesn't get sent in the URL anymoreа потом Session variables are like cookies - they're name-value pairs sent along with a request for a page. Что именно происходит? Отправляется ли он при следующем запросе?
КПМГ

19

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

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

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


1
Не могли бы вы немного прояснить это: «Теперь для каждого идентификатора сеанса сервер сохраняет некоторую структуру данных, которая позволяет ему хранить данные, специфичные для пользователя, эту структуру данных вы можете абстрактно называть сеансом».? Какую конкретную информацию о клиенте хранит сервер?
realPK

Не могли бы вы немного прояснить это: «Теперь для каждого идентификатора сеанса сервер сохраняет некоторую структуру данных, которая позволяет ему хранить данные, специфичные для пользователя, эту структуру данных вы можете абстрактно называть сеансом».? Какую конкретную информацию о клиенте хранит сервер?
Габ 是 好人

Тот же вопрос, что и выше, было бы полезно, если бы вы ответили.
Сурадж Джейн

4

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.