Quels sont les avantages et les inconvénients techniques de localStorage, sessionStorage, session et cookies, et quand dois-je les utiliser l'un par rapport à l'autre?
Quels sont les avantages et les inconvénients techniques de localStorage, sessionStorage, session et cookies, et quand dois-je les utiliser l'un par rapport à l'autre?
Réponses:
Il s'agit d'une question de portée extrêmement large, et de nombreux avantages / inconvénients seront contextuels à la situation.
Dans tous les cas, ces mécanismes de stockage seront spécifiques à un navigateur individuel sur un ordinateur / appareil individuel. Toute exigence de stockage de données sur une base continue entre les sessions devra impliquer votre côté serveur d'applications - très probablement en utilisant une base de données, mais éventuellement XML ou un fichier texte / CSV.
localStorage, sessionStorage et les cookies sont toutes des solutions de stockage client. Les données de session sont conservées sur le serveur où elles restent sous votre contrôle direct.
localStorage et sessionStorage sont des API relativement nouvelles (ce qui signifie que tous les navigateurs hérités ne les prendront pas en charge) et sont presque identiques (à la fois dans les API et les capacités) à la seule exception de la persistance. sessionStorage (comme son nom l'indique) n'est disponible que pour la durée de la session du navigateur (et est supprimé lorsque l'onglet ou la fenêtre est fermée) - il survit cependant aux rechargements de page ( guide de stockage DOM source - Mozilla Developer Network ).
De toute évidence, si les données que vous stockez doivent être disponibles sur une base continue, localStorage est préférable à sessionStorage - bien que vous devriez noter que les deux peuvent être effacées par l'utilisateur, vous ne devez donc pas compter sur l'existence continue des données dans les deux cas.
localStorage et sessionStorage sont parfaits pour conserver les données non sensibles nécessaires dans les scripts client entre les pages (par exemple: préférences, scores dans les jeux). Les données stockées dans localStorage et sessionStorage peuvent facilement être lues ou modifiées à partir du client / navigateur et ne doivent donc pas être utilisées pour le stockage de données sensibles ou liées à la sécurité dans les applications.
Cela est également vrai pour les cookies, ceux-ci peuvent être altérés de manière triviale par l'utilisateur, et les données peuvent également être lues à partir de ceux-ci en texte brut - donc si vous souhaitez stocker des données sensibles, la session est vraiment votre seule option. Si vous n'utilisez pas SSL, les informations des cookies peuvent également être interceptées en transit, en particulier sur un wifi ouvert.
Du côté positif, les cookies peuvent avoir un degré de protection appliqué contre les risques de sécurité comme le Cross-Site Scripting (XSS) / injection de script en définissant un indicateur HTTP uniquement, ce qui signifie que les navigateurs modernes (de support) empêcheront l'accès aux cookies et aux valeurs à partir de JavaScript ( cela empêchera également votre propre JavaScript légitime d'y accéder). Ceci est particulièrement important avec les cookies d'authentification, qui sont utilisés pour stocker un jeton contenant les détails de l'utilisateur connecté - si vous avez une copie de ce cookie, à toutes fins utiles, vous devenez cet utilisateur dans la mesure où l'application Web est concernés, et ont le même accès aux données et fonctionnalités que l'utilisateur.
Étant donné que les cookies sont utilisés à des fins d'authentification et de persistance des données utilisateur, tous les cookies valides pour une page sont envoyés du navigateur au serveur pour chaque demande adressée au même domaine - cela inclut la demande de page d'origine, toute demande Ajax ultérieure, toutes les images, feuilles de style, scripts et polices. Pour cette raison, les cookies ne doivent pas être utilisés pour stocker de grandes quantités d'informations. Le navigateur peut également imposer des limites sur la taille des informations pouvant être stockées dans les cookies. Les cookies sont généralement utilisés pour stocker des jetons d'identification pour l'authentification, la session et le suivi publicitaire. Les jetons ne sont généralement pas des informations lisibles par l'homme en soi, mais des identifiants chiffrés liés à votre application ou base de données.
En termes de capacités, les cookies, sessionStorage et localStorage vous permettent uniquement de stocker des chaînes - il est possible de convertir implicitement les valeurs primitives lors de la définition (celles-ci devront être reconverties pour les utiliser comme type après lecture), mais pas les objets ni les tableaux (il est possible de les sérialiser en JSON pour les stocker à l'aide des API). Le stockage de session vous permettra généralement de stocker toutes les primitives ou objets pris en charge par votre langage / framework côté serveur.
Comme HTTP est un protocole sans état - les applications Web n'ont aucun moyen d'identifier un utilisateur lors des visites précédentes en revenant sur le site Web - les données de session reposent généralement sur un jeton de cookie pour identifier l'utilisateur pour les visites répétées (bien que rarement les paramètres d'URL puissent être utilisés pour dans le même but). Les données auront généralement un délai d'expiration glissant (renouvelé à chaque visite de l'utilisateur) et, en fonction de votre serveur / cadre, les données seront stockées en cours de traitement (ce qui signifie que les données seront perdues si le serveur Web se bloque ou est redémarré) ou en externe dans un serveur d'état ou une base de données. Cela est également nécessaire lors de l'utilisation d'une ferme Web (plusieurs serveurs pour un site Web donné).
Comme les données de session sont entièrement contrôlées par votre application (côté serveur), c'est le meilleur endroit pour tout ce qui est sensible ou sécurisé par nature.
L'inconvénient évident des données côté serveur est l'évolutivité - les ressources du serveur sont nécessaires pour chaque utilisateur pendant la durée de la session, et que toutes les données nécessaires côté client doivent être envoyées avec chaque demande. Comme le serveur n'a aucun moyen de savoir si un utilisateur accède à un autre site ou ferme son navigateur, les données de session doivent expirer après un certain temps pour éviter que toutes les ressources du serveur ne soient utilisées par des sessions abandonnées. Lorsque vous utilisez des données de session, vous devez donc être conscient de la possibilité que les données aient expiré et aient été perdues, en particulier sur les pages avec de longs formulaires. Il sera également perdu si l'utilisateur supprime ses cookies ou change de navigateur / appareil.
Certains frameworks / développeurs Web utilisent des entrées HTML cachées pour conserver les données d'une page d'un formulaire à une autre afin d'éviter l'expiration de la session.
localStorage, sessionStorage et les cookies sont tous soumis à des règles de «même origine», ce qui signifie que les navigateurs doivent empêcher l'accès aux données à l'exception du domaine qui définit les informations pour commencer.
Pour plus d'informations sur les technologies de stockage client, voir Dive Into Html 5 .
sessionStorage
supprimé à la fermeture de la fenêtre ou de l'onglet?
Avantages :
Inconvénients :
Avantages:
Les inconvénients:
Les données sont renvoyées au serveur pour chaque requête HTTP (HTML, images, JavaScript, CSS, etc.) - augmentant la quantité de trafic entre le client et le serveur.
En règle générale, les éléments suivants sont autorisés:
Avantages:
localStorage
.Les inconvénients:
localStorage
, cela fonctionne sur la même politique d'origine . Ainsi, les données stockées ne seront disponibles que sur la même origine.Check -over cross -tabs - comment faciliter la communication entre les onglets du navigateur multi-origine.
OK, LocalStorage comme on l'appelle c'est le stockage local pour vos navigateurs, il peut économiser jusqu'à 10 Mo , SessionStorage fait la même chose, mais comme son nom l'indique, il est basé sur la session et sera supprimé après la fermeture de votre navigateur, peut également économiser moins que LocalStorage, comme jusqu'à 5 Mo , mais les cookies sont de très petites données stockées dans votre navigateur, qui peuvent économiser jusqu'à 4 Ko et sont accessibles via le serveur ou le navigateur à la fois ...
J'ai également créé l'image ci-dessous pour montrer les différences en un coup d'œil:
Ce sont des propriétés de l'objet 'window' en JavaScript, tout comme le document est l'une des propriétés d'un objet window qui contient des objets DOM.
La propriété de stockage de session conserve une zone de stockage distincte pour chaque origine donnée qui est disponible pour la durée de la session de page, c'est-à-dire aussi longtemps que le navigateur est ouvert, y compris les rechargements de page et les restaurations.
Le stockage local fait la même chose, mais persiste même lorsque le navigateur est fermé et rouvert.
Vous pouvez définir et récupérer les données stockées comme suit:
sessionStorage.setItem('key', 'value');
var data = sessionStorage.getItem('key');
De même pour localStorage.
sessionStorage
même un nouvel onglet est une nouvelle fenêtre. Ainsi, tout ce qui est stocké pour un domaine spécifique dans un onglet ne sera pas disponible pour le même domaine dans l'onglet suivant.
Stockage local: il conserve les données d'informations utilisateur sans date d'expiration, ces données ne seront pas supprimées lorsque l'utilisateur fermera les fenêtres du navigateur, elles seront disponibles pour le jour, la semaine, le mois et l'année.
Dans le stockage local, vous pouvez stocker 5 à 10 Mo de données hors ligne.
//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
Stockage de session: c'est la même chose que la date de stockage local, sauf qu'il supprimera toutes les fenêtres lorsque les fenêtres du navigateur seront fermées par un utilisateur Web.
Le stockage en session peut stocker jusqu'à 5 Mo de données
//set the value to a object in session storege
sessionStorage.myNameInSession = "Krishna";
Session : Une session est une variable globale stockée sur le serveur. Chaque session se voit attribuer un identifiant unique qui est utilisé pour récupérer les valeurs stockées.
Cookies : les cookies sont des données, stockées dans de petits fichiers texte sous forme de paires nom-valeur, sur votre ordinateur. Une fois qu'un cookie a été défini, toutes les demandes de page qui suivent renvoient le nom et la valeur du cookie.
L'API Web Storage fournit des mécanismes par lesquels les navigateurs peuvent stocker en toute sécurité des paires clé / valeur, d'une manière beaucoup plus intuitive que l'utilisation de cookies. L' API de stockage Web étend l' Window
objet avec deux nouvelles propriétés - Window.sessionStorage
et Window.localStorage
. - l'invocation de l'un d'eux créera une instance de l'objet Storage, à travers laquelle les éléments de données peuvent être définis, récupérés et supprimés. Un objet de stockage différent est utilisé pour sessionStorage
et localStorage
pour chaque origine (domaine).
Les objets de stockage sont de simples magasins de valeurs-clés , similaires aux objets, mais ils restent intacts pendant le chargement des pages .
localStorage.colorSetting = '#a4509b';
localStorage['colorSetting'] = '#a4509b';
localStorage.setItem('colorSetting', '#a4509b');
Les clés et les valeurs sont toujours des chaînes . Pour stocker n'importe quel typeconvert it to String
puis le stocker. Il est toujours recommandé d'utiliser desStorage interface
méthodes.
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));
Les deux mécanismes de Web Storage sont les suivants:
Stockage « Le stockage local écrit les données sur le disque, tandis que le stockage de session écrit les données dans la mémoire uniquement. Toutes les données écrites dans le stockage de session sont purgées à la fermeture de votre application.
Le stockage maximum disponible est différent par navigateur , mais la plupart des navigateurs ont mis en place au moins le w3c recommandé limite de stockage maximale de 5MB .
+----------------+--------+---------+-----------+--------+
| | Chrome | Firefox | Safari | IE |
+----------------+--------+---------+-----------+--------+
| LocalStorage | 10MB | 10MB | 5MB | 10MB |
+----------------+--------+---------+-----------+--------+
| SessionStorage | 10MB | 10MB | Unlimited | 10MB |
+----------------+--------+---------+-----------+--------+
Toujours intercepter les erreurs de sécurité et de dépassement de quota de LocalStorage
QuotaExceededError : Lorsque les limites de stockage dépassent sur cette fonctionwindow.sessionStorage.setItem(key, value);
, il déclenche une exception DOMException «QuotaExceededError» si la nouvelle valeur n'a pas pu être définie. (Le réglage peut échouer si, par exemple, l'utilisateur a désactivé le stockage pour le site ou si le quota a été dépassé.)
DOMException. QUOTA_EXCEEDED_ERR a 22 ans , exemple de violon .
SecurityError :Uncaught SecurityError: Access to 'localStorage' is denied for this document
.
CHROME:-Privacy and security « Content settings « Cookies « Block third-party cookies.
StorageEvent «L'événement de stockage est déclenché sur l'objet Window d'un document lorsqu'une zone de stockage change. Lorsqu'un agent utilisateur doit envoyer une notification de stockage pour un document, l'agent utilisateur doit mettre en file d'attente une tâche pour déclencher un événement nommé stockage sur l'objet Window de l'objet Document, à l'aide de StorageEvent.
Remarque: Pour un exemple réel, voir Démonstration de stockage Web . consultez le code source
Écoutez l'événement de stockage sur dom / Window pour détecter les changements dans le stockage. violon .
Cookies (cookie Web, cookie de navigateur) Les cookies sont des données, stockées dans de petits fichiers texte sous forme de paires nom-valeur, sur votre ordinateur.
Accès JavaScript à l'aide de Document.cookie
De nouveaux cookies peuvent également être créés via JavaScript à l'aide de la propriété Document.cookie, et si l'indicateur HttpOnly n'est pas défini, les cookies existants sont également accessibles à partir de JavaScript.
document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);
// logs "yummy_cookie=choco; tasty_cookie=strawberry"
Cookies sécurisés et HttpOnly Mécanisme de gestion des états HTTP
Les cookies sont souvent utilisés dans les applications Web pour identifier un utilisateur et sa session authentifiée
Lors de la réception d'une demande HTTP, un serveur peut envoyer un en - tête Set-Cookie avec la réponse. Le cookie est généralement stocké par le navigateur, puis le cookie est envoyé avec les demandes adressées au même serveur dans un en-tête HTTP Cookie.
Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Les cookies de session seront supprimés lorsque le client est fermé. Ils ne spécifient pas les directives Expires ou Max-Age.
Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/
Les cookies permanents expirent à une date spécifique (Expire) ou après une durée spécifique (Max-Age).
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
L'en-tête de requête HTTP Cookie contient des cookies HTTP stockés précédemment envoyés par le serveur avec l'en-tête Set-Cookie. Les cookies HTTP uniquement ne sont pas accessibles via JavaScript via la propriété Document.cookie, les API XMLHttpRequest et Request pour atténuer les attaques contre les scripts intersites (XSS).
Les cookies sont principalement utilisés à trois fins:
Les cookies ont été inventés pour résoudre le problème "comment se souvenir des informations sur l'utilisateur":
Exemple GitHubGist
En résumé,
LocalStorage :
Le stockage Web peut être considéré de manière simplifiée comme une amélioration des cookies, offrant une capacité de stockage beaucoup plus grande. La taille disponible est de 5 Mo, ce qui représente considérablement plus d'espace pour travailler qu'avec un cookie 4K Ko typique.
Les données ne sont pas renvoyées au serveur pour chaque requête HTTP (HTML, images, JavaScript, CSS, etc.), ce qui réduit la quantité de trafic entre le client et le serveur.
Les données stockées dans localStorage persistent jusqu'à leur suppression explicite. Les modifications apportées sont enregistrées et disponibles pour toutes les visites actuelles et futures du site.
Il fonctionne sur la même politique d'origine. Ainsi, les données stockées ne seront disponibles que sur la même origine.
Biscuits:
Nous pouvons définir le délai d'expiration de chaque cookie
La limite de 4K est pour le cookie entier, y compris le nom, la valeur, la date d'expiration, etc. Pour prendre en charge la plupart des navigateurs, gardez le nom sous 4000 octets et la taille globale du cookie sous 4093 octets.
Les données sont renvoyées au serveur pour chaque requête HTTP (HTML, images, JavaScript, CSS, etc.) - augmentant la quantité de trafic entre le client et le serveur.
sessionStorage:
Les modifications ne sont disponibles que par fenêtre (ou onglet dans les navigateurs comme Chrome et Firefox). Les modifications apportées sont enregistrées et disponibles pour la page actuelle, ainsi que les visites futures sur le site dans la même fenêtre. Une fois la fenêtre fermée, le stockage est supprimé Les données ne sont disponibles qu'à l'intérieur de la fenêtre / onglet dans lequel elles ont été définies.
Les données ne sont pas persistantes, c'est-à-dire qu'elles seront perdues une fois la fenêtre / l'onglet fermée. Comme localStorage, il fonctionne sur la même politique d'origine. Ainsi, les données stockées ne seront disponibles que sur la même origine.