Які технічні плюси та мінуси localStorage, sessionStorage, сесії та файлів cookie, і коли я використовую один за іншим?

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

У всіх випадках ці механізми зберігання будуть специфічними для окремого браузера на окремому комп'ютері / пристрої. Будь-яка вимога зберігати дані на постійній основі протягом сеансів повинна включати сторону вашого сервера додатків - швидше за все, використовуючи базу даних, але, можливо, XML або текстовий / CSV файл.

localStorage, sessionStorage та cookies - це рішення для зберігання клієнтів. Дані сесії зберігаються на сервері, де вони залишаються під вашим безпосереднім контролем.

localStorage та sessionStorage

localStorage та sessionStorage є відносно новими API (це означає, що не всі застарілі браузери підтримуватимуть їх) і майже однакові (як в API, так і в можливостях) за винятком лише постійності. sessionStorage (як випливає з назви) доступний лише протягом тривалості сеансу веб-переглядача (і видаляється, коли вкладка чи вікно закрито) - проте воно переживає перезавантаження сторінок (джерело посібника з зберігання DOM - Mozilla Developer Network ).

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

localStorage і sessionStorage ідеально підходять для збереження нечутливих даних, необхідних у клієнтських скриптах між сторінками (наприклад: налаштування, результати в іграх). Дані, що зберігаються у localStorage та sessionStorage, можна легко читати чи змінювати з боку клієнта / браузера, тому не слід покладатися на них для зберігання в програмах чутливих даних, пов’язаних із безпекою.

Печиво

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

З позитивної сторони файли cookie можуть мати ступінь захисту від ризиків для безпеки, таких як Cross-Site Scripting (XSS) / Incript Script, встановивши лише прапор HTTP, що означає, що сучасні (підтримуючі) браузери будуть перешкоджати доступу до файлів cookie та значень з JavaScript ( це також перешкоджатиме доступу до них вашого власного, законного JavaScript). Це особливо важливо для файлів cookie аутентифікації, які використовуються для зберігання маркера, що містить дані про користувача, який увійшов у систему - якщо у вас є копія цього файлу cookie, то для всіх намірів і цілей ви стаєте цим користувачем, наскільки це веб-додаток і мають однаковий доступ до даних та функцій, які має користувач.

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

localStorage vs. sessionStorage vs. Cookies

Що стосується можливостей, файли cookie, sessionStorage та localStorage дозволяють зберігати лише рядки - можливе неявне перетворення примітивних значень при встановленні (їх потрібно буде перетворити назад, щоб використовувати їх як їх тип після читання), але не об'єкти чи масиви (можна JSON серіалізувати їх, щоб зберігати їх за допомогою API). Зберігання сеансу, як правило, дозволяє зберігати будь-які примітиви або об'єкти, підтримувані вашою стороною сервера.

Сторона клієнта проти сервера

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

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

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

Деякі веб-фреймворки / розробники використовують приховані введення HTML для зберігання даних з однієї сторінки форми на іншу, щоб уникнути закінчення сеансу.

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

Для подальшого читання про технології зберігання клієнтів див. Dive Into Html 5 .

1. LocalStorage

   Плюси :

   1. Веб-сховище можна розглядати спрощено як поліпшення файлів cookie, забезпечуючи значно більшу ємність пам’яті. Якщо ви подивитесь на вихідний код Mozilla, ми можемо побачити, що 5120 КБ ( 5 МБ, що становить 2,5 мільйона символів у Chrome) - це розмір пам’яті за замовчуванням для всього домену. Це дає вам значно більше місця для роботи, ніж типовий cookie розміром 4 Кб.
   2. Дані не надсилаються назад на сервер для кожного запиту HTTP (HTML, зображення, JavaScript, CSS тощо) - зменшуючи кількість трафіку між клієнтом та сервером.
   3. Дані, що зберігаються в localStorage, зберігаються до явного видалення. Внесені зміни зберігаються та доступні для всіх поточних та майбутніх відвідувань сайту.

   Мінуси :

   1. Це працює на політиці одного походження . Отже, дані, що зберігаються, будуть доступні лише того самого джерела.

2. Печиво

   Плюси:

   1. У порівнянні з іншими, AFAIK нічого не має.

   Мінуси:

   1. Ліміт 4K призначений для всього файлу cookie, включаючи ім'я, значення, термін дії тощо.

   2. Дані надсилаються назад на сервер для кожного запиту HTTP (HTML, зображення, JavaScript, CSS тощо) - збільшуючи кількість трафіку між клієнтом та сервером.

      Зазвичай дозволяється:

      • 300 печива загалом
      • 4096 байт на печиво
      • 20 файлів cookie на домен
      • 81920 байт на домен (з огляду на 20 файлів cookie максимуму 4096 = 81920 байт.)

3. сховище

   Плюси:

   1. Це схоже на localStorage.
   2. Дані не є стійкими, тобто дані доступні лише для кожного вікна (або вкладки в таких браузерах, як Chrome і Firefox). Дані доступні лише під час сеансу сторінки. Внесені зміни зберігаються та доступні для поточної сторінки, а також для майбутніх відвідувань сайту у цьому ж вікні. Після закриття вікна сховище видаляється.

   Мінуси:

   1. Дані доступні лише у вікні / вкладці, в якій вони були встановлені.
   2. Мовляв localStorage, це працює на політиці одного походження . Отже, дані, що зберігаються, будуть доступні лише того самого джерела.

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

Гаразд, LocalStorage, як його називають, це локальне сховище для ваших браузерів, він може заощадити до 10 Мб , SessionStorage робить те саме, але, як видно з назви, це сеанс, який буде видалено після закриття веб-переглядача, також може зекономити менше, ніж LocalStorage, як-от до 5 Мб , але куки-файли - це дуже крихітні дані, що зберігаються у вашому браузері, що дозволяє заощадити 4 КБ та отримати доступ до них через сервер чи браузер ...

Я також створив зображення нижче, щоб побачити відмінності з першого погляду:

Це властивості "віконного" об'єкта в JavaScript, подібно до того, що документ є одним із властивостей об'єкта вікна, який містить об'єкти DOM.

Властивість Session Storage підтримує окрему область зберігання для кожного заданого джерела, доступну протягом тривалості сеансу сторінки, тобто доки браузер відкритий, включаючи перезавантаження та відновлення сторінки.

Локальне зберігання робить те саме, але зберігається навіть тоді, коли браузер закритий та відкритий.

Ви можете встановити та отримати збережені дані таким чином:

sessionStorage.setItem('key', 'value');

var data = sessionStorage.getItem('key');

Аналогічно для localStorage.

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

У локальному сховищі можна зберігати офлайн-дані 5-10 Мб.

//Set the value in a local storage object
localStorage.setItem('name', myName);

//Get the value from storage object
localStorage.getItem('name');

//Delete the value from local storage object
localStorage.removeItem(name);//Delete specifice obeject from local storege
localStorage.clear();//Delete all from local storege

Зберігання сеансу: це так само, як дата локального зберігання, за винятком того, що вона видалить усі вікна, коли вікна браузера закриті користувачем Інтернету.

У сховищі сеансів можна зберігати до 5 mb даних

//set the value to a object in session storege
sessionStorage.myNameInSession = "Krishna";

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

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

API веб-сховища забезпечує механізми, за допомогою яких браузери можуть безпечно зберігати пари ключів / значень набагато більш інтуїтивно, ніж використання файлів cookie. API Web Storage розширює Windowоб'єкт з двома новими властивостями - Window.sessionStorageі Window.localStorage. - виклик одного з них створить екземпляр об’єкта Storage, за допомогою якого елементи даних можна встановлювати, отримувати та вилучати. Інший об'єкт зберігання використовується для sessionStorageі localStorageдля кожного походження (домен).

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

localStorage.colorSetting = '#a4509b';
localStorage['colorSetting'] = '#a4509b';
localStorage.setItem('colorSetting', '#a4509b');

Клавіші та значення - це завжди рядки . Щоб зберігати будь-який тип,convert it to Stringа потім зберігати його. Завжди рекомендується використовуватиStorage interfaceметоди.

var testObject = { 'one': 1, 'two': 2, 'three': 3 };
// Put the object into storage
localStorage.setItem('testObject', JSON.stringify(testObject));
// Retrieve the object from storage
var retrievedObject = localStorage.getItem('testObject');
console.log('Converting String to Object: ', JSON.parse(retrievedObject));

Два механізми веб-зберігання такі:

• sessionStorage підтримує окрему область зберігання для кожного заданого джерела ^{Політика однакового походження} , доступна протягом тривалості сеансу сторінки (доки браузер відкритий, включаючи перезавантаження та відновлення сторінок).
• localStorage робить те саме, але зберігається навіть тоді, коли браузер закритий та відкритий.

Зберігання « Місцеве зберігання записує дані на диск, тоді як сеансове зберігання записує дані лише в пам'ять. Будь-які дані, записані у сховище сеансу, видаляються, коли додаток закривається.

Зберігання максимально доступні відрізняються від браузера , але більшість браузерів реалізували принаймні w3c рекомендовані максимальну межу зберігання 5МБ .

+----------------+--------+---------+-----------+--------+
|                | Chrome | Firefox | Safari    |  IE    |
+----------------+--------+---------+-----------+--------+
| LocalStorage   | 10MB   | 10MB    | 5MB       | 10MB   |
+----------------+--------+---------+-----------+--------+
| SessionStorage | 10MB   | 10MB    | Unlimited | 10MB   |
+----------------+--------+---------+-----------+--------+

Завжди вловлюйте безпеку LocalStorage, а помилки перевищені квоти

• QuotaExceededError : Коли межі зберігання перевищують цю функціюwindow.sessionStorage.setItem(key, value);, вона видає виняток DOMException "QuotaExceededError", якщо нове значення не вдалося встановити. (Налаштування може не вдатися, якщо, наприклад, користувач вимкнув сховище для сайту або якщо квота перевищена.)

  DOMException. QUOTA_EXCEEDED_ERR - 22 , приклад скрипка .

• SecurityError :Uncaught SecurityError: Access to 'localStorage' is denied for this document.

  CHROME:-Privacy and security « Content settings « Cookies « Block third-party cookies.

StorageEvent «Подія зберігання запускається на об’єкт Window документа, коли змінюється область зберігання. Коли користувальницький агент повинен надсилати повідомлення про зберігання для Документу, агент користувача повинен поставити в чергу завдання для запуску події з назвою "Зберігання" в об'єкті "Вікно" об'єкта Document, використовуючи StorageEvent.

Примітка. Для прикладу реального світу див. Демонстрацію веб-сховища . ^{перевірити вихідний код}

Прослухайте подію зберігання на dom / Window, щоб отримати зміни у сховищі. скрипка .

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

Доступ до JavaScript за допомогою Document.cookie

Нові файли cookie також можна створити через JavaScript, використовуючи властивість Document.cookie, і якщо прапор HttpOnly не встановлений, до існуючих файлів cookie можна також отримати доступ з JavaScript.

document.cookie = "yummy_cookie=choco"; 
document.cookie = "tasty_cookie=strawberry"; 
console.log(document.cookie); 
// logs "yummy_cookie=choco; tasty_cookie=strawberry"

Безпечний та HttpOnly механізм cookie- ^{механізму управління державою HTTP}

Файли cookie часто використовуються у веб-додатках для ідентифікації користувача та його аутентифікованого сеансу

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

Set-Cookie: <cookie-name>=<cookie-value> 
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>

Файли cookie сесії будуть видалені, коли клієнт закритий. Вони не визначають директиви Expires або Max-Age.

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/

Постійні файли cookie закінчуються в певну дату (Закінчується) або через певний проміжок часу (Max-Age).

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Заголовок запиту HTTP HTTP Cookie містить збережені файли cookie HTTP, попередньо надіслані сервером із заголовком Set-Cookie. Файли cookie, які містять лише HTTP, недоступні через JavaScript через властивість Document.cookie, API XMLHttpRequest і Request для зменшення атак проти міжсайтового сценарію (XSS).

Файли cookie в основному використовуються для трьох цілей:

• Управління сеансом «Логіни, кошики для гри, результати гри чи все інше, про що повинен пам’ятати сервер
• Персоналізація «Налаштування користувачів, теми та інші налаштування
• Відстеження (запис та аналіз поведінки користувачів) «Cookies мають пов’язаний з ними домен. Якщо цей домен збігається з доменом сторінки, на якій ви перебуваєте, печиво вважається першим файлом cookie. Якщо домен інший, це називається стороннім файлом cookie. Хоча файли cookie, що надсилаються сторонніми сторонами, надсилаються лише на сервер, який їх налаштовує, веб-сторінка може містити зображення або інші компоненти, що зберігаються на серверах в інших доменах (наприклад, банери оголошень). Файли cookie, що надсилаються через ці сторонні компоненти, називаються сторонніми файлами cookie і в основному використовуються для реклами та відстеження в Інтернеті.

Файли cookie були винайдені для вирішення проблеми "як запам'ятати інформацію про користувача":

• Коли користувач відвідує веб-сторінку, його ім’я може зберігатися у файлі cookie.
• Наступного разу, коли користувач відвідує сторінку, до запиту додаються файли cookie, що належать до цієї сторінки. Таким чином сервер отримує необхідні дані для «запам'ятовування» інформації про користувачів.

Приклад GitHubGist

Як підсумок,

• localStorage зберігається на різних вкладках чи вікнах, і навіть якщо ми закриваємо браузер, відповідно до політики безпеки домену та вибору користувача щодо обмеження квоти.
• Об'єкт sessionStorage не зберігається, якщо ми закриємо вкладку (контекст перегляду верхнього рівня), оскільки вона не існує, якщо ми переходимо через іншу вкладку чи вікно.
• Веб-зберігання (сеанс, локальний) дозволяє нам зберегти велику кількість пар ключів / значень і багато тексту, чого неможливо зробити за допомогою файлу cookie.
• Файли cookie, які використовуються для чутливих дій, повинні мати короткий термін експлуатації.
• Файли cookie в основному використовуються для реклами та відстеження в Інтернеті. Дивіться, наприклад, типи файлів cookie, які використовує Google .
• Файли cookie надсилаються з кожним запитом, тому вони можуть погіршити продуктивність (особливо для мобільних даних). Сучасними API для зберігання клієнтів є API веб-сховища (localStorage та sessionStorage) та IndexedDB.

LocalStorage :

• Веб-сховище можна розглядати спрощено як поліпшення файлів cookie, забезпечуючи набагато більшу ємність пам’яті. Доступний розмір - 5 Мб, що значно більше місця для роботи, ніж для типового файлу cookie 4 Кб.

• Дані не надсилаються назад на сервер для кожного запиту HTTP (HTML, зображення, JavaScript, CSS тощо) - зменшуючи кількість трафіку між клієнтом та сервером.

• Дані, що зберігаються в localStorage, зберігаються до явного видалення. Внесені зміни зберігаються та доступні для всіх поточних та майбутніх відвідувань сайту.

• Це працює на політиці одного походження. Отже, дані, що зберігаються, будуть доступні лише того самого джерела.

Файли cookie:

• Ми можемо встановити час закінчення терміну дії для кожного файлу cookie

• Ліміт 4K призначений для всього файлу cookie, включаючи ім'я, значення, термін дії тощо.

• Дані надсилаються назад на сервер для кожного запиту HTTP (HTML, зображення, JavaScript, CSS тощо) - збільшуючи кількість трафіку між клієнтом та сервером.

зберігання:

• Він схожий на localStorage.

• Зміни доступні лише для кожного вікна (або вкладки в таких браузерах, як Chrome і Firefox). Внесені зміни зберігаються та доступні для поточної сторінки, а також для майбутніх відвідувань сайту у цьому ж вікні. Після закриття вікна зберігання видаляється. Дані доступні лише у вікні / вкладці, в якій воно було встановлено.

• Дані не є стійкими, тобто вони будуть втрачені після закриття вікна / вкладки. Як і LocalStorage, він працює на політиці з однаковим походженням. Отже, дані, що зберігаються, будуть доступні лише того самого джерела.

ось швидкий огляд і з простим і швидким розумінням

від вчителя Бо Карнеса з freecodecamp