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

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

Але виходячи з ідентифікатора сеансу, як можна було б дізнатися моє ім’я користувача під час мого наступного обходу через сайт? Чи зберігає він дані на сервері як диктант, де ключовим моментом буде ідентифікатор сеансу, а такі деталі, як usernameі emailт.д., - значення?

Я тут дуже заплутався. Потрібна допомога.

Оскільки HTTP є без громадянства, для того, щоб пов’язати запит з будь-яким іншим запитом, вам потрібен спосіб зберігання даних користувачів між HTTP-запитами.

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

Рішення полягає в тому, щоб зберегти цю сторону сервера даних, дати їй "id" і нехай клієнт знає (і передавати назад при кожному запиті http) цей ідентифікатор. Там ви йдете, сеанси реалізовані. Або ви можете використовувати клієнт як зручне віддалене сховище, але ви зашифруєте дані та збережете секретну сторону сервера.

Звичайно, слід враховувати й інші аспекти, як, наприклад, ви не хочете, щоб люди викрадали сесії інших людей, ви хочете, щоб сеанси не тривали вічно, а закінчувались тощо.

У вашому конкретному прикладі ідентифікатор користувача (може бути ім'я користувача або інший унікальний ідентифікатор у вашій базі даних користувачів) зберігається в даних сеансу на стороні сервера після успішного ідентифікації. Тоді для кожного запиту HTTP, який ви отримуєте від клієнта, ідентифікатор сеансу (наданий клієнтом) вкаже вам правильні дані сеансу (зберігаються сервером), що містять автентифікований ідентифікатор користувача - таким чином ваш код буде знати, якого користувача він розмовляє.

Просте пояснення за аналогією

Уявіть, що ви перебуваєте в банку, намагаєтеся отримати гроші з вашого рахунку. Але темно; банк чорного тону: немає світла, і ви не можете побачити руку перед обличчям. Вас оточують ще 20 людей. Всі вони виглядають однаково. І всі мають однаковий голос. І кожен - потенційний поганий хлопець. Іншими словами, HTTP є без громадянства.

Цей банк - дивний тип банку - задля аргументів ось як все працює:

1. ви чекаєте в черзі (або он-лайн) і розмовляєте з касіром: ви робите запит на зняття грошей, а потім
2. вам доведеться коротко почекати на дивані, і через 20 хвилин
3. вам доведеться їхати і фактично збирати гроші у касира.

Але як скаже тобі казка, крім усіх інших?

Службовець не може бачити або легко впізнавати вас, пам’ятайте, бо вогні погашені. Що робити, якщо ваш касир віддає ваш 10 000 доларів США комусь іншому - неправильній особі ?! Це абсолютно важливо, щоб касир визнав вас тим, хто здійснив зняття коштів, щоб ви могли отримати гроші (або ресурс), про які ви вимагали.

Рішення:

Коли ви вперше з'явитесь до продавця, він чи вона вам щось таємно скаже:

"Коли колись ти розмовляєш зі мною, - каже касир, - спочатку ти повинен ідентифікувати себе як GNASHEU329 - таким чином я знаю, що це ти".

Ніхто більше не знає таємний пароль.

Приклад того, як я зняв готівку:

Тож я вирішую піти на 20 хвилин, а потім пізніше перейти до касира і сказати: "Я хотів би забрати свій вихід"

Теллер запитує мене: "хто ти такий ?!"

- Це я, містер Джордж Бенкс!

"Докажи це!"

А потім я кажу їм свій пароль: GNASHEU329

"Безумовно, містер Банкс!"

Це в основному, як працює сеанс. Це дозволяє однозначно ідентифікувати в морі мільйонів людей. Вам потрібно ідентифікувати себе щоразу, коли маєте справу з касиром.

Якщо у вас виникли якісь питання або ви незрозумілі - напишіть коментар, і я спробую це зрозуміти для вас.

Пояснення через картинки:

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

Перший раз, коли користувач підключає якийсь ідентифікатор сеансу (як це робиться, залежить від програмного забезпечення веб-сервера та типу аутентифікації / входу, який ви використовуєте на сайті). Як і файли cookie, вони зазвичай більше не надсилаються в URL-адресу, оскільки це проблема безпеки. Натомість він зберігається разом із купою інших матеріалів, які в сукупності також називають сеансом. Змінні сесії схожі на файли cookie - вони імена-значення, що надсилаються разом із запитом на сторінку та повертаються разом із сервером із сервера - але їх імена визначені у веб-стандарті.

Деякі змінні сеансу передаються як заголовки HTTP . Їх передають туди-сюди за лаштунками кожної сторінки, щоб вони не з’являлися у веб-переглядачі і всім розповідали щось, що може бути приватним. Серед них: USER_AGENT, або тип браузера, який запитує сторінку, REFERRER або сторінка, що посилається на запитувану сторінку тощо. Деякі програми веб-сервера додають власні заголовки або передають додаткові дані сеансу, характерні для серверного програмного забезпечення. Але стандартні досить добре документовані.

Сподіваюся, що це допомагає.

HTTP - протокол з'єднання без стану, тобто сервер не може розмежовувати різні з'єднання різних користувачів.

Звідси виходить файл cookie, коли клієнт вперше підключається до сервера, сервер генерує новий ідентифікатор сеансу, який пізніше буде надісланий клієнтові як значення cookie. І відтепер цей ідентифікатор сеансу ідентифікує це клієнтське з'єднання, оскільки в кожному запиті HTTP він побачить відповідний ідентифікатор сеансу всередині файлів cookie.

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

Подумайте про HTTP як про людину (А), яка має КОРОТКУВАННЯ ВІДПОВІДНИХ ВТРАТИ і забуває кожну людину, як тільки ця людина виходить з поля зору.

Тепер, щоб згадати різних людей, A робить фотографії цієї людини і зберігає її. На фотографії кожної людини є ідентифікаційний номер. Коли ця людина знову потрапляє в поле зору, ця особа повідомляє, що А ідентифікаційний номер відповідає А, і знаходить їх зображення за ідентифікаційним номером. І вуаля !!, знає хто ця людина.

Те саме з HTTP. Він страждає від КОРОТКОЇ ПЕРЕМОЖЕННІ ВТРАТИ. Він використовує Sessions для запису всього, що ви робили під час користування веб-сайтом, а потім, прийшовши знову, ідентифікує вас за допомогою файлів cookie (Cookie - це як маркер). Зображення - це Сесія тут, а ID - Cookie.