Сховище на стороні клієнта (Client-side storage)
Сучасні веб-браузери підтримують кілька способів зберігання даних із веб-сайтів на комп'ютері користувача - з дозволу користувача - щоб потім отримувати їх, коли це необхідно. Це дозволяє довгостроково зберігати дані, зберігати сайти або документи для використання без підключення до мережі, зберігати налаштування користувача для вашого сайту та багато іншого.
Раніше ми говорили про різницю між статичними та динамічними сайтами. Більшість сучасних веб-сайтів є динамічними - вони зберігають дані на сервері, використовуючи якусь базу даних (серверне сховище), а потім запускають код на стороні сервера, щоб витягти необхідні дані, вставити їх у шаблони статичних сторінок та передати отриманий HTML-код клієнту для відображення у браузері користувача.
Сховище за клієнта працює за схожими принципами, але використовується по-іншому. Воно складається з API-інтерфейсів JavaScript, які дозволяють зберігати дані на клієнті (тобто на комп'ютері користувача), а потім виймати їх при необхідності. Це має багато різних застосувань, таких як:
Персоналізація налаштувань сайту (наприклад, відображення вибраних користувачем віджетів, колірної схеми або розміру шрифту).
Збереження попередньої активності на сайті (наприклад, збереження вмісту кошика покупок з попереднього сеансу, запам'ятовування, чи користувач був авторизований раніше в системі).
Збереження даних і ресурсів локально, тому сайт буде швидше (і, можливо, економічніше) завантажуватися або використовуватися без підключення до мережі.
Збереження створених веб-програмою документів локально для використання в автономному режимі.
Часто сховища на сторонах клієнта та сервера використовуються спільно. Наприклад, ви повинні завантажити з бази даних пакет музичних файлів для веб-ігри, або музичний плеєр зберігає їх у базі даних за клієнта, і відтворює за необхідності.
Користувач повинен буде завантажити музичні файли лише один раз - під час наступних відвідувань їх буде вилучено з локальної бази даних.
Старий підхід: Cookie (HTTP cookie, web cookie, internet cookie, browser cookie)
Кукі (англ. cookie, букв. – «печиво») – невеликий фрагмент даних, відправлений веб-сервером і зберігається на комп'ютері користувача. Веб-клієнт (зазвичай веб-браузер) щоразу під час спроби відкрити сторінку відповідного сайту пересилає цей фрагмент даних веб-серверу у складі HTTP-запиту. Застосовується для збереження даних на стороні користувача, практично зазвичай використовується для:
автентифікації користувача;
зберігання персональних переваг та налаштувань користувача;
відстеження стану сеансу доступу користувача;
збирання статистики про користувачів.
Підтримки браузерами cookie (прийом, збереження та подальше пересилання серверу збережених cookie) вимагають багато сайтів з обмеженнями доступу, більшість інтернет-магазинів. Налаштування оформлення та поведінки багатьох веб-сайтів за індивідуальними уподобаннями користувача також базується на cookie.
Cookie легко перехопити і підмінити (наприклад, щоб отримати доступ до облікового запису), якщо користувач використовує нешифроване з'єднання з сервером. У групі ризику користувачі, які виходять в Інтернет за допомогою публічних точок доступу Wi-Fi і не використовують при цьому такі механізми, як SSL та TLS. Шифрування дозволяє також вирішити й інші проблеми, пов'язані з безпекою даних, що передаються.
Більшість сучасних браузерів дозволяє користувачам вибрати - приймати cookie чи ні, але їх відключення унеможливлює роботу з деякими сайтами. Крім того, за законами деяких країн (наприклад, згідно з постановою Євросоюзу від 2016 року, див. загальний регламент захисту даних) сайти повинні обов'язково запитувати згоду користувача перед встановленням cookie.
Призначення
Cookie використовуються веб-серверами для ідентифікації користувачів та зберігання даних про них.
Наприклад, якщо вхід на сайт здійснюється за допомогою cookie, то після введення користувачем своїх даних на сторінці входу cookie дозволяють серверу запам'ятати, що користувач вже ідентифікований і йому дозволено доступ до відповідних послуг та операцій.
Багато сайтів також використовують cookie для збереження налаштувань користувача. Ці настройки можуть використовуватися для персоналізації, яка включає вибір оформлення і функціональності. Наприклад, Вікіпедія дозволяє авторизованим користувачам вибрати дизайн сайту. Пошукова система Google дозволяє користувачам (у тому числі не зареєстрованим у ній) вибрати кількість результатів пошуку, що відображаються на одній сторінці.
Cookie також використовується для відстеження дій користувачів на сайті. Як правило, це робиться для збору статистики, а рекламні компанії на основі такої статистики формують анонімні профілі користувачів для більш точного націлювання реклами.
Типи cookie
Сесійні cookie : Сесійні cookie, також відомі як тимчасові cookie, існують лише у тимчасовій пам'яті, доки користувач знаходиться на сторінці веб-сайту. Браузер зазвичай видаляють сесійні cookie після того, як користувач закриває вікно браузера. На відміну від інших типів cookie, сесійні cookie не мають закінчення терміну дії, тому браузери розуміють їх як сесійні.
Постійні cookie : Замість видалення після закриття браузера, як це роблять сесійні cookie, постійні cookie-файли видаляються в певну дату або через певний проміжок часу. Це означає, що інформація про cookie буде передаватися на сервер щоразу, коли користувач відвідує веб-сайт, якому ці cookie належать. З цієї причини постійні cookie іноді називаються стежать cookie, оскільки вони можуть використовуватися рекламодавцями для запису про переваги користувача протягом тривалого часу. Однак вони також можуть використовуватися і в «мирних» цілях, наприклад, щоб уникнути повторного введення даних при кожному відвідуванні сайту.
Супер-cookie: Супер-cookie - це cookie-файл із джерелом домену верхнього рівня (наприклад, .ru) або загальнодоступним суфіксом (наприклад, .co.uk). Звичайні cookie, навпаки, мають походження від конкретного доменного імені, наприклад, example.com. Супер-cookie можуть бути потенційною проблемою безпеки, тому часто блокуються веб-браузерами. Якщо браузер розблокує шкідливий веб-сайт, зловмисник може встановити супер-cookie та потенційно порушити або видати себе за законні запити користувачів на інший веб-сайт, який використовує той самий домен верхнього рівня або загальнодоступний суфікс, що й шкідливий веб-сайт. Наприклад, супер-cookie з походженням .com може зловмисно вплинути на запит до example.com, навіть якщо файл cookie не був створений із сайту example.com. Це може бути використане для підробки логіну або зміни інформації користувача. Публічний список суфіксів допомагає знизити ризик, який є супер-cookie. Публічний список суфіксів – це ініціатива крос-вендорів, метою якого є надання точного та актуального списку суфіксів доменних імен. У старих версіях браузерів може бути відсутній актуальний список, і тому вони будуть уразливі для супер-cookie з певних доменів. Термін "supercookie" (супер-cookie) іноді використовується для відстеження технологій, які не використовують файли cookie HTTP. У серпні 2011 року на веб-сайтах Microsoft було виявлено два такі механізми «супер-cookie»: синхронізація файлів cookie, що породжує cookie MUID (унікальний ідентифікатор машини), та cookie ETag.
Зомбі-cookie: Оскільки cookie можна легко видалити з браузера, програмісти шукають способи ідентифікувати користувачів навіть після повного очищення історії браузера. Одним з таких рішень є зомбі-cookie (або evercookie, або persistent cookie) - не видалені або важко видалені cookie, які можна відновити в браузері за допомогою JavaScript. Це можливо тому, що для зберігання cookie сайт одночасно використовує всі доступні сховища браузера (HTTP ETag, Session Storage, Local Storage, Indexed DB), у тому числі і сховища додатків, таких як Flash Player (Local Shared Objects), Microsoft Silverlight (Isolated Storage) та Java (Java persistence API). Коли програма виявляє відсутність у браузері cookie-файлу, інформація про який є в інших сховищах,
Робота cookie
Як і будь-який інший HTTP-заголовок, cookie повинні передаватися в браузер до того, як будуть передані будь-які інші дані, включаючи порожні рядки та символи пробілів (це обмеження HTTP-протоколу).
GET /index.html HTTP/1.1
Сервер відповідає, надсилаючи запитувану сторінку разом із текстом, що містить HTTP-відповідь. Там може бути вказівка браузеру зберегти cookie:
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
GET /spec.html HTTP/1.1
Cookie: name=value
Accept: /
Цей запит відрізняється від першого запиту тим, що містить рядок, який сервер надіслав браузеру раніше. Таким чином, сервер дізнається, що цей запит пов'язаний із попереднім. Сервер відповідає, відправляючи потрібну сторінку і, можливо, додавши нові cookie.
Значення cookie може бути змінено сервером шляхом надсилання нових рядків Set-Cookie: name=new_value. Після цього браузер замінює старе cookie з тим самим ім'ям на новий рядок.
Cookie також можуть встановлюватися програмами мовами типу JavaScript, вбудованими в текст сторінок, або аналогічними скриптами, що працюють у браузері. JavaScript для цього використовується властивість cookie об'єкта document - document.cookie. Наприклад, document.cookie="temperature=20" створить cookie під іменем «temperature» та значенням 20.
Аутентифікація
Cookie можуть використовуватися сервером для пізнання раніше автентифікованих користувачів. Це відбувається так:
Користувач вводить ім'я користувача та пароль у текстових полях сторінки входу та надсилає їх на сервер.
Сервер отримує ім'я користувача та пароль, перевіряє їх і, за їх правильності, відправляє сторінку успішного входу, прикріпивши cookie з певним ідентифікатором сесії. Це cookie може бути дійсним не тільки для поточної сесії браузера, але може бути налаштовано і на тривале зберігання.
Щоразу, коли користувач запитує сторінку з сервера, браузер автоматично відправляє cookie з ідентифікатором сесії серверу. Сервер перевіряє ідентифікатор за власною базою ідентифікаторів і, за наявності в базі такого ідентифікатора, «дізнається» користувача.
Цей метод широко використовується на багатьох сайтах, наприклад на Yahoo!, у Вікіпедії та у Facebook'і.
Багато браузерів (зокрема Opera, FireFox) шляхом редагування властивостей cookie можуть керувати поведінкою веб-сайтів. Змінивши термін закінчення непостійних (сесійних) cookie, можна, наприклад, отримати формально-необмежену сесію після авторизації на будь-якому сайті. Можливість редагування cookie стандартними засобами відсутня в Internet Explorer. Але, скориставшись іншими механізмами, наприклад JavaScript, користувач може змінити cookie-файл. Більше того, існує можливість замінити сесійні cookie на постійні (із зазначенням терміну придатності).
Однак, серверне програмне забезпечення може відслідковувати такі спроби. Для цього сервер видає cookie на певний термін і записує дату закінчення cookie у себе або, в зашифрованому вигляді, у самих cookie, щоразу, коли користувач звертається до сервера. Якщо cookie, надісланий браузером, має дату придатності, відмінну від тієї, що зберігається на сервері або міститься в cookie, значить, має місце спроба заміни дати придатності cookie. Сервер може відреагувати, наприклад, запросивши у користувача повторну авторизацію.
Тестування файлів cookie
Тестування файлів cookie - це процес перевірки того, чи файли cookie працюють належним чином. Під час тестування файлів cookie тестувальникам необхідно перевірити статус файлу cookie, термін дії файлу cookie, доступність файлу cookie, обмеження безпеки тощо.
Приклад чек-листа для Cookie testing:
Файли cookie створюються коректно на диску;
Поведінка при відмові включити куки:
Чи відображається відповідне повідомлення для Користувачів, щоб увімкнути файли cookie для доступу до сайту?
Чи є обхідний шлях для доступу до сайту для браузерів із вимкненими файлами cookie.
Працездатність після видалення файлів cookie;
Працездатність після пошкодження (шляхом редагування) файлів cookie та неможливість входу в систему після редагування даних для входу;
Особисті або конфіденційні дані, що зберігаються у файлі cookie, знаходяться у зашифрованому форматі;
Крос-браузерне тестування файлів cookie;
Не повинно бути надмірного використання файлів cookie.
Недоліки куки
Концепція зберігання за клієнта існує вже давно. З перших днів Інтернету, використовували cookies для зберігання інформації, щоб персоналізувати досвід користувача на веб-сайтах. Це рання форма сховища на стороні клієнта, яка зазвичай використовується в Інтернеті.
Через цей вік існує ряд проблем - як технічних, так і з точки зору досвіду користувача - пов'язаних з файлами cookie. Ці проблеми настільки значні, що при першому відвідуванні сайту людям, які живуть у Європі, показуються повідомлення, які інформують їх про те, чи будуть вони використовувати файли cookie для зберігання даних про них. Це пов'язано з частиною законодавства Європейського Союзу, відомого як EU Cookie Directive.
Вони застаріли, вони мають багато проблем з безпекою, і вони не здатні зберігати складні дані. При цьому існують кращі, більш сучасні способи зберігання ширшого спектра даних на комп'ютері користувача.
Єдиною перевагою файлів cookie є те, що вони підтримуються дуже старими браузерами, тому, якщо ваш проект вимагає, щоб ви підтримували застарілі браузери (наприклад, Internet Explorer 8 або попередні версії), файли cookie можуть бути корисними, але для більшості проектів ви не потрібно більше вдаватися до них.
Чому, як і раніше, створюються нові сайти за допомогою файлів cookie? Це відбувається головним чином через звички розробників, використання старих бібліотек, які все ще використовують файли cookie, і наявність безлічі веб-сайтів, що надають застарілі довідкові та навчальні матеріали для навчання зберігання даних.
Новий підхід: Web Storage та IndexedDB
Сучасні браузери мають набагато простіші та ефективніші API для зберігання даних на стороні клієнта, ніж при використанні файлів cookie.
Інтернет-сховище спрощено можна розглядати як удосконалення куки. Тим не менш, воно відрізняється від кукі в деяких ключових напрямках:
Розмір сховища: інтернет-сховище підтримує набагато більше місця на диску в порівнянні з куки, якому доступно всього 4 Кбайта, що приблизно в 1000 разів менше ніж у веб-сховища (5 Мбайт на домен у Mozilla Firefox, Google Chrome і Opera, і 10 Мбайт в Internet Explorer);
Інтерфейс на стороні клієнта: на відміну від cookie, які можуть бути доступні як на сервері, так і на стороні клієнта, веб-сховище потрапляє виключно під компетенцію сценаріїв (скриптів) на стороні клієнта. Дані інтернет-сховища не передаються на сервер при кожному запиті HTTP, і веб-сервер не може записати безпосередньо в інтернет-сховище;
Локальне сховище та сесійне сховище: інтернет-сховище пропонує дві різні області: локальне сховище та сесійне сховище, які різняться за своїми обсягами та часом життя. Дані розміщуються в окреме для кожного домену локальне сховище (воно доступне всім скриптів з домену, який спочатку додав дані) і зберігаються після закриття браузера. Сесія зберігається за принципом одна сторінка - одне вікно і обмежується життям цього вікна, тобто для кожного відкритого вікна створюється нова сесія, яка припиняє своє існування при закритті вікна і не залежить від домену, що її відкрив. Збереження сесії призначене для надання окремих екземплярів одного і того ж веб-додатку для роботи в різних вікнах, не заважаючи один одному.
Інтерфейс і модель даних: інтернет-сховище в даний час надає програмний інтерфейс краще, ніж кукі. Інтерфейс є асоціативним масивом моделі даних, де ключі і значення є рядками. Додатковий API для доступу до структурованих даних на основі SQL знаходиться на розгляді робочої групи W3C.
Що нас чекає у майбутньому: Cache API
Джерела:
Дод. матеріал:
Last updated