Quelle est la différence entre localStorage, sessionStorage, session et cookies?


533

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?


2
Il s'agit également d'un sujet connexe intéressant à consulter: stockage local HTML5 vs stockage de session ( stackoverflow.com/questions/5523140/… )
Sarin JS

2
Notez également que les cookies de session vivent aussi longtemps que le navigateur WINDOW est ouvert (pas l'onglet dans lequel ils ont été définis) MAIS sessionStorage est annulé dès que vous fermez l'onglet ...
yar1

Oui, la session est également un type de cookie. La caractéristique est qu'il est transitoire là où le cookie est persistant
Faris Rayhan

@ yar1 Une fenêtre de navigateur particulière est un élément d'interface utilisateur non pertinent.
curiousguy

Réponses:


719

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

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.

Biscuits

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.

localStorage vs sessionStorage vs Cookies

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.

Côté client vs 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 .


34
Attention: sessionStorage, localStorage ne sont pas appropriés pour les informations d'authentification. Ils ne sont pas envoyés automatiquement au serveur. Cela signifie que si un utilisateur modifie l'URL manuellement ou clique sur des liens HTML, vous n'obtiendrez pas d'informations d'authentification. Même si vous réécrivez des liens HTML, vous êtes obligé de transmettre les informations d'authentification sur l'URL qui est un non-non de sécurité. À la fin de la journée, vous serez obligé d'utiliser des cookies. Voir stackoverflow.com/q/26556749/14731 pour une rubrique connexe.
Gili

23
Sera sessionStoragesupprimé à la fermeture de la fenêtre ou de l'onglet?
trysis

34
Le sessionStorage sera supprimé lorsque l'onglet sera fermé.
rcarrillopadron

10
@Gili pourquoi la transmission des informations d'authentification sur l'URL est-elle la seule option si vous n'utilisez pas de cookies? Pourquoi ne pas le passer dans un en-tête HTTP?
par

21
@Gili Vous avez raison de dire qu'il n'envoie pas automatiquement, mais vous avez tort de dire que ce n'est pas approprié. J'utilise localStorage et sessionStorage dans de nombreuses applications de production différentes que j'ai pour mes clients et je n'ai pas eu une vulnérabilité en raison de la dépendance à localStorage / sessionStorage couplée à l'envoi de l'id et d'un jeton dans les en-têtes. Même moins de charge sur le serveur. De plus, je lie un événement à la page de rechargement et aux crochets de chargement d'application pour demander à mon backend si ces utilisateurs se sont encore authentifiés. Fonctionne très bien. Bonne authentification! EDIT: un jeton CSRF avec tout ce qui ajoute encore plus de sécurité.
NodeDad

74
  1. Stockage local

    Avantages :

    1. 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. Si vous regardez le code source de Mozilla, nous pouvons voir que 5120 Ko ( 5 Mo, ce qui équivaut à 2,5 millions de caractères sur Chrome) est la taille de stockage par défaut pour un domaine entier. Cela vous donne beaucoup plus d'espace pour travailler qu'avec un cookie 4Ko typique.
    2. 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.
    3. 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.

    Inconvénients :

    1. Il fonctionne sur la même politique d'origine . Ainsi, les données stockées ne seront disponibles que sur la même origine.
  2. Biscuits

    Avantages:

    1. Par rapport aux autres, il n'y a rien d'AFAIK.

    Les inconvénients:

    1. 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.
    2. 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:

      • 300 cookies au total
      • 4096 octets par cookie
      • 20 cookies par domaine
      • 81920 octets par domaine (compte tenu de 20 cookies de taille maximale 4096 = 81920 octets.)
  3. sessionStorage

    Avantages:

    1. C'est semblable à localStorage.
    2. Les données ne sont pas persistantes, c'est-à-dire que les données ne sont disponibles que par fenêtre (ou onglet dans les navigateurs comme Chrome et Firefox). Les données ne sont disponibles que pendant la session de page. 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 inconvénients:

    1. Les données sont disponibles uniquement dans la fenêtre / l'onglet dans lequel elles ont été définies.
    2. Comme 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.


13
Cookies : " Les données sont renvoyées au serveur pour chaque requête HTTP ". Dans certains cas d'utilisation (comme dans le processus d'authentification), cela peut également être considéré comme un avantage. sessionStorage : " Les modifications ne sont disponibles que par fenêtre (ou onglet dans les navigateurs comme Chrome et Firefox) ". Je pense qu'il est préférable de le formuler " Les modifications ne sont disponibles que pendant la session de page ". Une session de page dure aussi longtemps que le navigateur est ouvert et survit malgré les rechargements et les restaurations de page (de MDN: developer.mozilla.org/en/docs/Web/API/Window/sessionStorage )
Deniz

Mise à jour! Merci @DenizToprak
softvar

1
@softvar: sessionStorage - Con 2 .: "Les données ne sont pas persistantes, c'est-à-dire qu'elles seront perdues une fois la fenêtre / l'onglet fermée." - Ce n'est certainement pas un défaut. Je dirais que c'est un avantage. C'est du stockage "session" après tout. Il est conçu pour fonctionner de cette façon.
devstructor

@devstructor Oui, vous avez raison. Je l'ai pensé en termes de stockage local de certaines données. J'ai mis à jour la réponse. Merci d'avoir fait remarquer cela.
softvar

57

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:

LocalStorage, SessionStorage et cookies


25

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.


10
Juste pour ajouter - car sessionStoragemê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.
RBT

5

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.


2

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' Windowobjet avec deux nouvelles propriétés - Window.sessionStorageet 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 sessionStorageet localStoragepour 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 Stringpuis le stocker. Il est toujours recommandé d'utiliser desStorage interfacemé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:

  • sessionStorage gère une zone de stockage distincte pour chaque origine donnée. Politique de même origine disponible pour la durée de la session de page (tant que le navigateur est ouvert, y compris les rechargements et les restaurations de page).
  • localStorage fait la même chose, mais persiste même lorsque le navigateur est fermé et rouvert.

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

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:

  • Gestion de session «Connexions, paniers d'achat, scores de jeu ou tout autre élément dont le serveur doit se souvenir
  • Personnalisation «Préférences utilisateur, thèmes et autres paramètres
  • Suivi (enregistrement et analyse du comportement des utilisateurs) «Les cookies ont un domaine qui leur est associé. Si ce domaine est le même que le domaine de la page sur laquelle vous vous trouvez, les cookies sont réputés être des cookies propriétaires. Si le domaine est différent, il s'agit d'un cookie tiers. Alors que les cookies propriétaires sont envoyés uniquement au serveur qui les définit, une page Web peut contenir des images ou d'autres composants stockés sur des serveurs dans d'autres domaines (comme des bannières publicitaires). Les cookies qui sont envoyés via ces composants tiers sont appelés cookies tiers et sont principalement utilisés pour la publicité et le suivi sur le Web.

Les cookies ont été inventés pour résoudre le problème "comment se souvenir des informations sur l'utilisateur":

  • Lorsqu'un utilisateur visite une page Web, son nom peut être enregistré dans un cookie.
  • La prochaine fois que l'utilisateur visite la page, des cookies appartenant à la page sont ajoutés à la demande. De cette façon, le serveur obtient les données nécessaires pour "mémoriser" les informations sur les utilisateurs.

Exemple GitHubGist


En résumé,

  • localStorage persiste sur différents onglets ou fenêtres, et même si nous fermons le navigateur, conformément à la politique de sécurité du domaine et aux choix des utilisateurs concernant la limite de quota.
  • L'objet sessionStorage ne persiste pas si nous fermons l'onglet (contexte de navigation de niveau supérieur) car il n'existe pas si nous surfons via un autre onglet ou une autre fenêtre.
  • Le stockage Web (session, local) nous permet d'économiser une grande quantité de paires clé / valeur et beaucoup de texte, ce qui est impossible à faire via un cookie.
  • Les cookies utilisés pour des actions sensibles ne doivent avoir qu'une courte durée de vie.
  • Cookies principalement utilisés pour la publicité et le suivi sur le Web. Voir par exemple les types de cookies utilisés par Google .
  • Les cookies sont envoyés à chaque demande, ce qui peut détériorer les performances (en particulier pour les connexions de données mobiles). Les API modernes pour le stockage client sont l'API de stockage Web (localStorage et sessionStorage) et IndexedDB.

2

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:

  • Il est similaire à localStorage.
  • 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.


0

voici un examen rapide et avec une compréhension simple et rapide

entrez la description de l'image ici

du professeur Beau Carnes du freecodecamp

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.