Browser Local Storage Overview
Introduction
cookie
A cookie is a data (usually encrypted) that some websites store on the user’s local terminal in order to identify the user’s identity and track the session.
webStorage
webStorage is one of the local storage solutions in HTML5, including sessionStorag and localStorage, the difference between the two differences in the life cycle.
websql and indexeddb
IndexedDB is a low-level API for the client to store large amounts of structured data. The API uses an index to achieve a high-performance search for the data. WebStorage is useful for storing less data, but it is not useful for storing a lot of structured data. IndexedDB provides a solution.
websql is the early storage standards, is no longer maintenance, steering indexeddb, but websql better compatibility. But indexeddb is the future, so the next main indexeddb
Four contrast
Types of | Life cycle | Storage size | Communicate with the server | Scopes | scenes to be used |
---|---|---|---|---|---|
Cookie | Generally generated by the server, you can set the expiration time, the default is to disable the browser after the failure | 4k or so | Can carry each time in the http header, but save too much data will bring performance problems | You can set the primary domain name by .setDomain | It is not recommended to store data in the cookie, if necessary, to store synchronization access to the page must be brought to the server information, such as the site user login information |
localStorage | Permanently saved unless cleared | 5m or so | Can only be stored on the browser side | Subdomains are independent of each other | Store some of the user status and data, ease the server pressure |
sessionStorage | Only the current tab page, close the browser or the new tab is empty | 5m or so | Can only be stored on the browser side | Different tabs can not be shared | It is recommended to store some of the current page refresh need to store, and do not need to leave the tab when the information left, according to this to determine whether the user to refresh, restore music video playback |
indexeddb | Permanently saved unless cleared | A separate database does not have a size limit, but may limit the size of each Indexeddb database, such as Firefox in the user interface will only be stored for more than 50 MB size of the BLOB (binary large object) request permissions, the overall basic no size limit | Can only be stored on the browser side | Subdomains are independent of each other | Offline application or webapp can consider using indexeddb or websql to access data |
【Tip】 sessionStorage can only be shared under a tab, that is, if you open a page from the current tab page, sessionStorage data is empty. But if you restore the closed page, then chrome and firefox sessionStorage will be restored, but Safari will not.
webStorage and indexeddb compatibility
webStorage compatibility
Chrome | Firefox | IE | Opera | Safari | |
---|---|---|---|---|---|
localStorage | 4 | 3.5 | 8 | 10.50 | 4 |
sessionStorage | 5 | 2 | 8 | 10.50 | 4 |
Basic browsers are supported
indexeddb compatibility
Chrome | Firefox | IE | Opera | Safari | |
---|---|---|---|---|---|
Asynchronous API | 12 [webkit] | 16.0 (16.0) 4.0 (2.0) [moz] | 10 【ms】 | Not realized | Not realized |
Synchronization API | Not realized | Not realized | Not realized | Not realized | Not realized |
Currently poor compatibility
webStorage API
LocalStorage and sessionStorage usage are the same, the following show examples of the use of sessionStorage.
Of course, you can also use the object to set the way to the assignment.
However, the official proposal only use webStorage API (getItem, removeItem, key, length), to avoid the use of object key storage some of the defects, please click here for details
storage event
There are storage events for webStorage. When the storage changes, the storage event is triggered.
The condition here is that the data has changed, and if the current storage area is empty, even if the call to clear () will not trigger the event. Or if you set a value that is the same as the existing value by settingItem(), the event will not fire.
storage attribute
Attribute name | description |
---|---|
key | On behalf of the attribute name changes. When the clear () method is cleared after all the property name becomes null. Read only (read only). |
newValue | Newly added value. When executed by the clear () method or deleted by the attribute name, the value becomes null. Read only (read only). |
oldValue | The original value is changed to null by the clear () method or replaced by a new value. Read only. |
storageArea | The storage object being manipulated. Read only. |
url | key The URL of the document corresponding to the changed object. Read only. |
The following describes the use of multi-tab page sessionStorage will use chestnuts.
The multi-tab page uses sessionStorage
In the recent use of vuejs write completely before and after the separation of the project, when doing login authentication, in the end how to store user authentication information.
Because the system security requirements are relatively high, requiring the user to close the tab when the session immediately expires, the use of cookies to save the sensitive token is not appropriate. If you use localstorage, the localstorage data is still there, and the requirements are not met.
Think only use sessionStorage.
But embarrassing is that the use of sessionStorage is no longer able to share more pages. Each time you open a new tab, it will jump to the login page, the user experience is not friendly.
In simple terms, if the new tab if there is no sessionStorage data, it will trigger a localstorage modify events, then in the existing label received this event, it will be the current page sessionStorage data stored in localstorage, but immediately Removed. But in the new tab will listen to the event, you can get to the sessionStorage data, which will ensure that the new tab page can also get sessionStorage, but also to ensure that localstorage does not exist token information.
IndexedDB
Usage is not as simple as sessionStorage, but the following two articles on the basic indexeddb usage are relatively clear. No extra finishing.