Відмінності між файлами cookie та сеансами?


154

Я займаюся навчанням в Інтернеті та вивчаю JSP & Servlets . Я маю деякі знання проHttpSession - я використав це в деяких своїх зразкових проектах.

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

Чи печиво та сеанс однакові? Які відмінності між ними?


Дивіться також це питання: < stackoverflow.com/questions/356562/… > Зокрема, зауваження щодо підписаних файлів cookie.
Джоель Куехорн

Я думаю, що друга відповідь на це питання є більш доречною, якщо ви обрали це як найкращу відповідь, багато людей прочитають її.
Сурай Джайн

Відповіді:


180

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

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


10
" передача його за URL-адресою (що становить загрозу безпеці). " насправді обидва підходи мають ризики безпеки (різні). Секретний ідентифікатор у URL-адресі може бути захищеним, якщо це зроблено належним чином, і якщо користувач розуміє, що URL-адреса є секретною і ніколи не може публікуватися на загальнодоступному форумі.
curiousguy

1
"Ідентифікатор можна передати в URL-адресу або зберегти у файлі cookie сеансу." . Де? сторона клієнта чи сервера? дякую, що уточнили більше.
Адіб Аруй

4
@whitelettersandblankspaces Файл cookie сеансу зберігається на клієнті (і його значення містить унікальний ідентифікатор сеансу, який надсилається з кожним запитом, щоб відобразити сеанс браузера на сеанс користувача на сервері).
WynandB

306

Файл cookie - це просто короткий текстовий рядок, який надсилається туди-назад між клієнтом і сервером. Ви можете зберігати name=bob; password=asdfasфайли cookie та надсилати їх туди-назад, щоб ідентифікувати клієнта на стороні сервера. Ви можете подумати про це як провести обмін з банком, який не має короткострокової пам’яті, і вам потрібно визначити себе для кожної операції. Звичайно, використання файлу cookie для зберігання такої інформації є жахливо небезпечним. Файли cookie також мають обмежений розмір.

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

Переклад цього на веб-сервери: сервер буде зберігати відповідну інформацію в об'єкті сеансу та створювати ідентифікатор сеансу, який він буде відправляти клієнту назад у cookie. Коли клієнт відправляє назад cookie, сервер може просто шукати об’єкт сеансу за допомогою ідентифікатора. Отже, якщо ви видалите файл cookie, сеанс буде втрачено.

Ще одна альтернатива - сервер використовувати переписування URL для обміну ідентифікатором сеансу.

Припустимо, у вас було посилання - www.myserver.com/myApp.jsp Ви можете перейти через сторінку і переписати кожну URL-адресу як www.myserver.com/myApp.jsp?sessionID=asdfабо навіть www.myserver.com/asdf/myApp.jspі обміняти таким чином ідентифікатор. Ця методика обробляється контейнером веб-додатків і зазвичай її включають, встановлюючи конфігурацію для використання сеансів без cookie.


29
Це чудове пояснення, прикріплене до великої аналогії реального світу. Цю відповідь слід більше оцінювати. Дуже доступний для новачків, які найчастіше задають таке питання.
користувач798719

2
Що станеться, якщо я користувач, а хтось інший дізнається мій ідентифікатор сеансу?
Марія Інес Парнісарі

3
@ I19 Можливо, вони можуть видати себе за себе. Це трапилося в сценаріях азартних ігор в Інтернеті - обнюхуйте wifi в готелі, викрадіть ідентифікатор сеансу та отримайте доступ до облікового запису. Забезпечення сеансу - це зовсім інша історія.
Кріс Кадмор

2
То хто першим створює печиво? Сервер чи клієнт? Або це залежить від програми? (Я б сказав , що сервер , так як в іншому випадку це може мати небезпечні наслідки, але я думаю , що це варто mentionning?)
НСЗ

4
@nha Сервер створює сеанс і передає його у відповідь з файлом cookie. Сеанс створюється залежно від логіки програми, коли ви хочете, щоб він був створений. Клієнт також може створити файл cookie, але це може бути не дуже корисним у сценарії ідентифікації сеансу, оскільки сервер може не знати, яке значення представляє сеанс.
Azeem

4

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



1

Файл cookie - це в основному глобальний масив, доступ до якого здійснюється через веб-браузери. Багато разів використовується для надсилання / отримання значень. він діє як механізм зберігання для доступу до значень між формами. Веб-браузер може відключити браузер, що додає обмеження щодо їх використання порівняно з сеансом.

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


0

Google JSESSIONID . Це пояснить, як API сервлетів спочатку використовує перезапис URL-адрес, а потім, якщо файли cookie ввімкнено, файли cookie для керування сеансами.

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


0

Сесія на Asp.net:

1.Зберігає дані по всій програмі.

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

3. Сесії - це файли на стороні сервера, що містять інформацію про користувача. [Сесії - це унікальний ідентифікатор, який відображає їх конкретним користувачам]

Переклад цього на веб-сервери: сервер буде зберігати відповідну інформацію в об'єкті сеансу та створювати ідентифікатор сеансу, який він буде відправляти клієнту назад у cookie. Коли клієнт відправляє назад cookie, сервер може просто шукати об’єкт сеансу за допомогою ідентифікатора. Отже, якщо ви видалите файл cookie, сеанс буде втрачено.


0

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


0

Файли cookie зберігаються у веб-переглядачі як формат текстового файлу. Зберігається обмежений обсяг даних. Він дозволяє лише 4 Кб [4096 байт] . $ _ COOKIE не містить декілька файлів cookie з тим самим іменем

ми можемо легко отримати доступ до значень файлів cookie. Тому це менш безпечно . Функція setcookie () повинна з'явитися перед

<html> 

тег.

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

Посилання: різниця між cookie-та-сесіями


Ну, насправді ви можете зберігати кілька даних у файлах cookie. Також сеанси дійсно не можуть містити необмежену кількість даних. Ви майже обмежені обсягом оперативної пам’яті.
Корай Тугай
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.