当 cookie 被首次引入时,它是浏览器保存数据的唯一方式。之后又有了很多新的选择:Web Storage API、IndexedDB 和 Cache API。那么 cookie 死了吗?我们来看看这些在浏览器中存储数据的技术。
Cookies
Cookie 是由服务器发送或在客户端上设置的信息单位,保存在用户的本地浏览器上。它们会自动附加到每个请求上。由于 HTTP 是无状态协议,因此 cookie 允许将信息存储在客户端上,以便将其他上下文数据传给该服务器。
Cookie 有一些标志,对于提高数据的安全性非常有用。 HttpOnly
标志阻止用 JavaScript 访问 cookie 的行为,只有附加在 HTTP 请求上时才能访问它们。这非常适合防止通过 XSS(跨站点脚本)攻击造成数据泄露。
此外,Secure
标志确保仅在通过 HTTPS 协议发送请求时才发送 cookie。 SameSite
标志,可以设置为 lax
或 strict
(它们的差异看这里),可用于帮助防止 CSRF(跨站点请求伪造)请求。它告诉浏览器只有在请求是与请求者在同一域中的 URL 时才发送 cookie。
什么时候使用 cookies?
那么,在哪些情况下你希望获得 Cookie?最常见的应用场景之一是授权 token 。由于 HttpOnly
标志为 XSS 攻击添加了额外的保护层,SameSite
可以防止 CSRF,而 Secure
可以确保你的 cookie 被加密,这使你的身份验证token 有额外的保护层。
由于 auth token 非常小,因此你无需担心请求过大。此外由于它们会自动附加到每个请求,因此使用 cookie 可以在服务器上确定用户是否经过身份验证。这对于服务器呈现的内容非常有用,例如你希望将未经过身份验证的用户重定向到登录页面。
Cookie 的另一个用途是存储用户的语言代码。由于你可能希望在大多数请求中访问用户的语言,因此你可以利用它自动附加。
如何使用 cookies?
前面经讨论了要使用 cookie 的原因,现在来看看你可以如何使用 cookie。要从服务器上给客户端设置 cookie,需要在 HTTP 响应中添加 Set-Cookie
标头。 Cookie 应采用 key=value
的格式。如果你要在 Node.js 程序中设置 cookie,你的代码可能像下面这样:
response.setHeader('Set-Cookie', ['user_lang=en-us', 'user_theme=dark_mode']);
这将会设置两个 cookie:它将 user_lang
设置为 en-us
,将 user_theme
设置为 dark_mode
。
Cookie 也可以由客户端操纵。要设置 cookie,可以用 key=value
的格式为 document.cookie
赋值。如果 key 已存在,则会被覆盖掉。
document.cookie = 'user_lang=es-es';
如果已经定义了 user_lang
,它现在等于es-es
。
你可以通过访问 document.cookie
值来查看所有的 cookie。这将返回一串以分号做分隔的键值对。
document.cookie = 'user_lang=en-us'; document.cookie = 'user_theme=light_mode'; console.log(document.cookie); // 'user_lang=en-us; user_theme=light_mode;'
要增加键值对的可访问性,可以使用以下函数将此字符串解析为对象:
const parseCookies = x => x .split(';') .map(e => e.trim().split('=')) .reduce((obj, [key, value]) => ({...obj, [key]: value}), {});
If you need to set one of the flags onto your cookie, you can add them after a semicolon. For example, if you’d like to set the Secure
and SameSite
flags onto your cookie, you would do the following:
如果你需要将其中一个标志设置到 cookie 上,可以在分号后添加它们。例如你想在 Cookie 上设置 Secure
和 SameSite
标志,则可以执行以下操作:
document.cookie = 'product_ids=123,321;secure;samesite=lax'
由于 HTTPOnly
的作用是使 cookie 只能在服务器上访问,因此它只能由服务器添加。
除了这些安全标志之外,你还可以设置 Max-Age
( cookie 应该保存的秒数)或 Expires
(Cookie应该过期的日期)。如果这些都未设置,则 cookie 将跟随浏览器会话的持续时间。如果用户使用隐身模式,则会在用户会话关闭时删除 Cookie。
由于处理 cookie 的接口不是很友好,所以你可以使用诸如 js-cookie
之类的库来方便对其的操作。
Web Storage API
Web Storage API 是一种在本地存储数据的新选项。它在 HTML5 中中添加,Web Storage API 包括localStorage
和 sessionStorage
。虽然 cookie 通常处理 server/client 通信,但 Web Storage API 最适用于保存客户端数据。
我们已经将 cookie 作为在本地存储数据的选项,为什么还需要 Web 存储?其中一个原因是:由于 cookie 会自动添加到每个 HTTP 请求中,因此请求大小会变得臃肿。所以你可以用 Web Storage API 存储比 cookie 更大量的数据。
另一个优点是更直观的 API。如果使用 cookie,你需要手动解析 cookie 字符串来访问各个键。 Web Storage 使这更加容易。如果要设置或获取值,可以使用 setItem
或 getItem
。
localStorage.setItem('selected_tab', 'FAQ'); localSTorage.getItem('selected_tab'); // 'FAQ'
键和值都必须是字符串。如果你想保存一个对象或数组,可以在保存时调用 JSON.stringify()
并在读取时调用 JSON.parse()
来实现。
const product = { id: '123', name: 'Coffee Beans', }; localStorage.setItem('cached_product', JSON.stringify(product)); JSON.parse(localStorage.getItem('cached_product'));
local storage 的另一个用例是在多个选项卡之间同步数据。通过为 'storage'
事件添加侦听器,你可以在另一个选项卡或窗口中更新数据。
window.addEventListener('storage', () => { console.log('local storage has been updated'); });
仅当在另一个文档中修改本地或会话存储时才会触发此事件。也就是说,你无法在当前浏览器选项卡中侦听 storage 的更改。不幸的是,截至撰写本文时,存储事件监听器尚未在 Chrome 上得到支持。
那么localStorage
和 sessionStorage
之间有什么区别呢?与 cookie 不同,Web Storage API 没有过期或最大期限功能。如果使用 localStorage
,除非手动删除,否则数据将无限期保留。你可以通过运行 localStorage.removeItem('key')
来删除单个键的值,或者通过运行 localStorage.clear()
清除所有数据。
如果使用 sessionStorage
,则数据将仅持续到当前会话结束。如果你没有设置最大时间或过期,它将被视为与 cookie 保持的方式相似。在任何一种情况下,如果用户使用隐身,本地存储都不会在会话之间保留数据。
IndexedDB
如果 cookie 和 localStorage
都不符合你的要求,还有另一种选择:IndexedDB,一个浏览器内置的数据库系统。
当 localStorage
同步执行所有方法时,IndexedDB 会异步调用它们。这将会允许访问数据而不会阻塞其余代码。当你处理大量可能访问代价高昂的代码时,这非常有用。
IndexedDB 在其存储的数据类型方面也具有更大的灵活性。虽然 cookies 和 localStorage
仅限于存储字符串,但 IndexedDB 可以存储可以通过“结构化克隆算法”复制的任何类型的数据。这包括 Object
、 Date
、 File
、 Blob
、 RegEx
以及更多类型。
性能和灵活性增加的缺点是 IndexedDB 的 API 更低级且更复杂。幸运的是有许多库可以解决这个问题。
localForage
为 IndexedDB 提供了一个更简单的类似 localStorage
的 API。 PouchDB 提供了一个可以离线的存储 API,可以与在线 CouchDB 数据库同步。 idb 是一个小型库,具有更简单的基于 promise 的 API。 Dexie 添加了更强大的查询 API,同时保持了良好的性能。根据你的使用情况还有许多选择。
Cache API
另一种用于持久数据的专用工具是 Cache API。虽然它最初是为 service workers 创建的,但它可用于缓存任何网络请求。 Cache API 公开了 Window.caches
,它提供了保存和检索响应的方法,允许你保存可永远以后访问的 Requests
和 Responses
对。
例如,如果你想在从 API 请求响应之前检查浏览器的缓存以获取响应,则可以执行以下操作:
const apiRequest = new Request('https://www.example.com/items'); caches.open('exampleCache') // opens the cache .then(cache => { cache.match(apiRequest) // checks if the request is cached .then(cachedResponse => cachedResponse || // return cachedReponse if available fetch(apiRequest) // otherwise, make new request .then(response => { cache.put(apiRequest, response); // cache the response return response; }) }) .then(res => console.log(res)) })
第一次运行代码时,它将缓存响应。随后每次都会缓存请求,并且不会发出网络请求。
总结
在浏览器上存储数据的每种方法都有其自己的用途。如果信息很小,很敏感,并且可能在服务器上使用,那么 cookie 就是最佳选择。如果要保存更大且更不敏感的数据,Web Storage API 可能是更好的选择。
如果你打算存储大量结构化数据,IndexedDB 非常棒。 Cache API 用于存储来自 HTTP 请求的响应。根据你的需要,有很多工具可供使用。
作者:Adam Giese
翻译:疯狂的技术宅
原文:https://blog.logrocket.com/be…
未经允许不得转载:w3h5 » 超越Cookie,当今的客户端数据存储技术有哪些
原创文章,作者:Maggie-Hunter,如若转载,请注明出处:https://blog.ytso.com/150362.html