¿Cuáles son los pros y los contras técnicos de localStorage, sessionStorage, session y cookies, y cuándo usaría uno sobre el otro?

Esta es una pregunta de alcance extremadamente amplio, y muchos de los pros / contras serán contextuales a la situación.

En todos los casos, estos mecanismos de almacenamiento serán específicos para un navegador individual en una computadora / dispositivo individual. Cualquier requisito para almacenar datos de forma continua en las sesiones deberá involucrar el lado del servidor de su aplicación, lo más probable es que use una base de datos, pero posiblemente XML o un archivo de texto / CSV.

localStorage, sessionStorage y cookies son todas las soluciones de almacenamiento del cliente. Los datos de la sesión se guardan en el servidor donde permanecen bajo su control directo.

localStorage y sessionStorage

localStorage y sessionStorage son API relativamente nuevas (lo que significa que no todos los navegadores heredados las admitirán) y son casi idénticas (tanto en API como en capacidades) con la única excepción de la persistencia. sessionStorage (como su nombre lo indica) solo está disponible durante la sesión del navegador (y se elimina cuando se cierra la pestaña o ventana); sin embargo, sobrevive a la recarga de la página ( guía de almacenamiento DOM de origen - Red de desarrolladores de Mozilla ).

Claramente, si los datos que está almacenando deben estar disponibles de manera continua, localStorage es preferible a sessionStorage, aunque debe tener en cuenta que el usuario puede borrar ambos, por lo que no debe confiar en la existencia continua de datos en ninguno de los casos.

localStorage y sessionStorage son perfectos para la persistencia de datos no confidenciales necesarios dentro de los scripts del cliente entre páginas (por ejemplo: preferencias, puntajes en juegos). Los datos almacenados en localStorage y sessionStorage se pueden leer o cambiar fácilmente desde el cliente / navegador, por lo que no se debe confiar en ellos para el almacenamiento de datos confidenciales o relacionados con la seguridad dentro de las aplicaciones.

Galletas

Esto también es cierto para las cookies, estas pueden ser manipuladas trivialmente por el usuario, y los datos también se pueden leer en texto plano, por lo que si desea almacenar datos confidenciales, la sesión es realmente su única opción. Si no está utilizando SSL, la información de las cookies también puede ser interceptada en tránsito, especialmente en un wifi abierto.

En el lado positivo, las cookies pueden tener un grado de protección aplicado contra riesgos de seguridad como Cross-Site Scripting (XSS) / Script injection mediante la configuración de un indicador HTTP solamente que significa que los navegadores modernos (compatibles) evitarán el acceso a las cookies y valores desde JavaScript ( esto también evitará que tu propio JavaScript legítimo acceda a ellos). Esto es especialmente importante con las cookies de autenticación, que se utilizan para almacenar un token que contiene detalles del usuario que inició sesión; si tiene una copia de esa cookie, a todos los efectos se convierte en ese usuario en lo que respecta a la aplicación web. en cuestión, y tener el mismo acceso a los datos y la funcionalidad que tiene el usuario.

Como las cookies se utilizan para fines de autenticación y persistencia de los datos del usuario, todas las cookies válidas para una página se envían desde el navegador al servidor para cada solicitud al mismo dominio; esto incluye la solicitud de página original, cualquier solicitud posterior de Ajax, todas las imágenes, hojas de estilo, scripts y fuentes. Por esta razón, las cookies no deben usarse para almacenar grandes cantidades de información. El navegador también puede imponer límites en el tamaño de la información que se puede almacenar en las cookies. Por lo general, las cookies se usan para almacenar tokens de identificación para autenticación, sesión y seguimiento de publicidad. Los tokens generalmente no son información legible por humanos en sí mismos, sino identificadores cifrados vinculados a su aplicación o base de datos.

localStorage vs. sessionStorage vs. Cookies

En términos de capacidades, las cookies, sessionStorage y localStorage solo le permiten almacenar cadenas: es posible convertir implícitamente valores primitivos al configurar (estos deberán volver a convertirse para usarlos como su tipo después de la lectura) pero no Objetos o Matrices (es posible JSON serializarlos para almacenarlos usando las API). El almacenamiento de sesión generalmente le permitirá almacenar primitivas u objetos compatibles con su lenguaje / marco del lado del servidor.

Del lado del cliente frente al lado del servidor

Como HTTP es un protocolo sin estado (las aplicaciones web no tienen forma de identificar a un usuario de visitas anteriores al regresar al sitio web), los datos de la sesión generalmente se basan en un token de cookie para identificar al usuario para las visitas repetidas (aunque rara vez se pueden usar parámetros de URL para El mismo propósito). Los datos generalmente tendrán un tiempo de caducidad variable (se renueva cada vez que el usuario visita) y, dependiendo de su servidor / marco, los datos se almacenarán en el proceso (lo que significa que los datos se perderán si el servidor web falla o se reinicia) o externamente en Un servidor de estado o una base de datos. Esto también es necesario cuando se utiliza una granja de servidores web (más de un servidor para un sitio web determinado).

Como los datos de la sesión están completamente controlados por su aplicación (lado del servidor), es el mejor lugar para cualquier cosa sensible o segura.

La desventaja obvia de los datos del lado del servidor es la escalabilidad: se requieren recursos del servidor para cada usuario durante la sesión, y que cualquier dato del cliente que se necesite debe enviarse con cada solicitud. Como el servidor no tiene forma de saber si un usuario navega a otro sitio o cierra su navegador, los datos de la sesión deben caducar después de un tiempo determinado para evitar que todos los recursos del servidor sean ocupados por sesiones abandonadas. Cuando utilice datos de sesión, debe tener en cuenta la posibilidad de que los datos hayan expirado y se hayan perdido, especialmente en páginas con formularios largos. También se perderá si el usuario elimina sus cookies o cambia de navegador / dispositivo.

Algunos frameworks / desarrolladores web usan entradas HTML ocultas para conservar los datos de una página de un formulario a otra para evitar el vencimiento de la sesión.

localStorage, sessionStorage y las cookies están sujetos a las reglas del "mismo origen", lo que significa que los navegadores deben impedir el acceso a los datos, excepto el dominio que establece la información para comenzar.

Para obtener más información sobre las tecnologías de almacenamiento del cliente, consulte Dive Into Html 5 .

1. Almacenamiento local

   Pros :

   1. El almacenamiento web puede verse de manera simple como una mejora en las cookies, proporcionando una capacidad de almacenamiento mucho mayor. Si observa el código fuente de Mozilla, podemos ver que 5120 KB ( 5 MB, que equivale a 2.5 millones de caracteres en Chrome) es el tamaño de almacenamiento predeterminado para un dominio completo. Esto le brinda considerablemente más espacio para trabajar que una cookie típica de 4KB.
   2. Los datos no se envían de vuelta al servidor para cada solicitud HTTP (HTML, imágenes, JavaScript, CSS, etc.), lo que reduce la cantidad de tráfico entre el cliente y el servidor.
   3. Los datos almacenados en localStorage persisten hasta que se eliminen explícitamente. Los cambios realizados se guardan y están disponibles para todas las visitas actuales y futuras al sitio.

   Contras :

   1. Funciona en la política del mismo origen . Por lo tanto, los datos almacenados solo estarán disponibles en el mismo origen.

2. Galletas

   Pros:

   1. En comparación con otros, no hay nada AFAIK.

   Contras:

   1. El límite de 4K es para toda la cookie, incluido el nombre, el valor, la fecha de caducidad, etc. Para admitir la mayoría de los navegadores, mantenga el nombre por debajo de 4000 bytes y el tamaño total de la cookie por debajo de 4093 bytes.

   2. Los datos se envían de vuelta al servidor para cada solicitud HTTP (HTML, imágenes, JavaScript, CSS, etc.), lo que aumenta la cantidad de tráfico entre el cliente y el servidor.

      Por lo general, se permiten los siguientes:

      • 300 galletas en total
      • 4096 bytes por cookie
      • 20 cookies por dominio
      • 81920 bytes por dominio (Dadas 20 cookies de tamaño máximo 4096 = 81920 bytes).

3. sessionStorage

   Pros:

   1. Es similar a localStorage.
   2. Los datos no son persistentes, es decir, los datos solo están disponibles por ventana (o pestaña en navegadores como Chrome y Firefox). Los datos solo están disponibles durante la sesión de la página. Los cambios realizados se guardan y están disponibles para la página actual, así como para futuras visitas al sitio en la misma ventana. Una vez que se cierra la ventana, se elimina el almacenamiento.

   Contras:

   1. Los datos solo están disponibles dentro de la ventana / pestaña en la que se configuraron.
   2. Al igual localStorage, funciona en la política del mismo origen . Por lo tanto, los datos almacenados solo estarán disponibles en el mismo origen.

Checkout cross -tabs : cómo facilitar la comunicación fácil entre pestañas de navegador de origen cruzado.

OK, LocalStorage , como se llama su almacenamiento local para sus navegadores, puede guardar hasta 10 MB , SessionStorage hace lo mismo, pero como su nombre lo dice, está basado en sesión y se eliminará después de cerrar su navegador, también puede ahorrar menos que LocalStorage, les gusta hasta 5 MB , pero las Cookies son datos muy pequeños que almacenan en su navegador, que pueden ahorrar hasta 4KB y se puede acceder a través del servidor o del navegador ...

También creé la imagen a continuación para mostrar las diferencias de un vistazo:

Estas son propiedades del objeto 'ventana' en JavaScript, al igual que el documento es una propiedad de un objeto ventana que contiene objetos DOM.

La propiedad Almacenamiento de sesión mantiene un área de almacenamiento separada para cada origen dado que está disponible durante la sesión de la página, es decir, siempre que el navegador esté abierto, incluidas las recargas y restauraciones de la página.

El Almacenamiento local hace lo mismo, pero persiste incluso cuando el navegador se cierra y se vuelve a abrir.

Puede configurar y recuperar datos almacenados de la siguiente manera:

sessionStorage.setItem('key', 'value');

var data = sessionStorage.getItem('key');

Del mismo modo para localStorage.

Almacenamiento local: mantiene los datos de información del usuario sin fecha de caducidad. Estos datos no se eliminarán cuando el usuario cierre las ventanas del navegador, estarán disponibles por día, semana, mes y año.

En el almacenamiento local puede almacenar datos fuera de línea 5-10mb.

//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

Almacenamiento de sesión: es igual que la fecha de almacenamiento local, excepto que eliminará todas las ventanas cuando un usuario web cierre las ventanas del navegador.

En la sesión, el almacenamiento puede almacenar hasta 5 mb de datos

//set the value to a object in session storege
sessionStorage.myNameInSession = "Krishna";

Sesión : una sesión es una variable global almacenada en el servidor. A cada sesión se le asigna una identificación única que se utiliza para recuperar los valores almacenados.

Cookies : las cookies son datos, almacenados en pequeños archivos de texto como pares de nombre-valor, en su computadora. Una vez que se ha establecido una cookie, todas las solicitudes de página que siguen devuelven el nombre y el valor de la cookie.

La API de almacenamiento web proporciona mecanismos mediante los cuales los navegadores pueden almacenar de forma segura pares clave / valor, de una manera mucho más intuitiva que el uso de cookies. La API de almacenamiento web amplía el Windowobjeto con dos nuevas propiedades, Window.sessionStoragey Window.localStorage. - invocar uno de estos creará una instancia del objeto Storage, a través del cual se pueden establecer, recuperar y eliminar elementos de datos. Se utiliza un objeto de almacenamiento diferente para sessionStoragey localStoragepara cada origen (dominio).

Los objetos de almacenamiento son almacenes de valores clave simples , similares a los objetos, pero permanecen intactos a través de las cargas de página .

localStorage.colorSetting = '#a4509b';
localStorage['colorSetting'] = '#a4509b';
localStorage.setItem('colorSetting', '#a4509b');

Las claves y los valores son siempre cadenas . Para almacenar cualquier tipoconvert it to Stringy luego almacenarlo. Siempre se recomienda usarStorage interfacemétodos.

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));

Los dos mecanismos dentro del almacenamiento web son los siguientes:

• sessionStorage mantiene un área de almacenamiento separada para cada origen determinado ^{Política del mismo origen} que está disponible durante la sesión de la página (siempre que el navegador esté abierto, incluidas las recargas y restauraciones de la página).
• localStorage hace lo mismo, pero persiste incluso cuando el navegador se cierra y se vuelve a abrir.

Almacenamiento « El almacenamiento local escribe los datos en el disco, mientras que el almacenamiento de la sesión escribe los datos solo en la memoria. Todos los datos escritos en el almacenamiento de la sesión se eliminan cuando se cierra la aplicación.

El almacenamiento máximo disponible es diferente por navegador , pero la mayoría de los navegadores han implementado al menos el límite de almacenamiento máximo recomendado por w3c de 5 MB .

+----------------+--------+---------+-----------+--------+
|                | Chrome | Firefox | Safari    |  IE    |
+----------------+--------+---------+-----------+--------+
| LocalStorage   | 10MB   | 10MB    | 5MB       | 10MB   |
+----------------+--------+---------+-----------+--------+
| SessionStorage | 10MB   | 10MB    | Unlimited | 10MB   |
+----------------+--------+---------+-----------+--------+

Siempre detecte los errores de seguridad y cuota de LocalStorage excedidos

• QuotaExceededError : cuando los límites de almacenamiento exceden esta funciónwindow.sessionStorage.setItem(key, value);, genera una excepción DOMException "QuotaExceededError" si no se puede establecer el nuevo valor. (La configuración podría fallar si, por ejemplo, el usuario ha deshabilitado el almacenamiento para el sitio, o si se ha excedido la cuota).

  DOMException. QUOTA_EXCEEDED_ERR es 22 , por ejemplo, violín .

• SecurityError :Uncaught SecurityError: Access to 'localStorage' is denied for this document.

  CHROME:-Privacy and security « Content settings « Cookies « Block third-party cookies.

StorageEvent «El evento de almacenamiento se activa en el objeto Window de un documento cuando cambia un área de almacenamiento. Cuando un agente de usuario debe enviar una notificación de almacenamiento para un Documento, el agente de usuario debe poner en cola una tarea para activar un evento denominado almacenamiento en el objeto Ventana del objeto Documento, utilizando StorageEvent.

Nota: para ver un ejemplo del mundo real, consulte Demostración de almacenamiento web . ^{mira el código fuente}

Escuche el evento de almacenamiento en dom / Window para ver los cambios en el almacenamiento. violín .

Cookies (cookie web, cookie del navegador) Las cookies son datos, almacenados en pequeños archivos de texto como pares de nombre-valor, en su computadora.

Acceso a JavaScript utilizando Document.cookie

También se pueden crear nuevas cookies a través de JavaScript utilizando la propiedad Document.cookie, y si no se establece el indicador HttpOnly, también se puede acceder a las cookies existentes desde JavaScript.

document.cookie = "yummy_cookie=choco"; 
document.cookie = "tasty_cookie=strawberry"; 
console.log(document.cookie); 
// logs "yummy_cookie=choco; tasty_cookie=strawberry"

Cookies seguras y HttpOnly ^{Mecanismo de gestión de estado HTTP}

Las cookies se usan a menudo en la aplicación web para identificar a un usuario y su sesión autenticada

Al recibir una solicitud HTTP, un servidor puede enviar un encabezado Set-Cookie con la respuesta. Por lo general, el navegador almacena la cookie y luego se envía con las solicitudes realizadas al mismo servidor dentro de un encabezado HTTP de cookie.

Set-Cookie: <cookie-name>=<cookie-value> 
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>

Las cookies de sesión se eliminarán cuando se cierre el cliente. No especifican las directivas Expires o Max-Age.

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/

Las cookies permanentes caducan en una fecha específica (caduca) o después de un período de tiempo específico (edad máxima).

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

El encabezado de solicitud HTTP de Cookie contiene cookies HTTP almacenadas enviadas previamente por el servidor con el encabezado Set-Cookie. Las cookies solo HTTP no son accesibles a través de JavaScript a través de la propiedad Document.cookie, las API XMLHttpRequest y Request para mitigar los ataques contra las secuencias de comandos entre sitios (XSS).

Las cookies se utilizan principalmente para tres propósitos:

• Gestión de sesiones «Inicios de sesión, carritos de compras, puntuaciones de juegos o cualquier otra cosa que el servidor deba recordar
• Personalización «Preferencias de usuario, temas y otras configuraciones
• Seguimiento (registro y análisis del comportamiento del usuario) «Las cookies tienen un dominio asociado. Si este dominio es el mismo que el dominio de la página en la que se encuentra, se dice que las cookies son cookies de origen. Si el dominio es diferente, se dice que es una cookie de terceros. Si bien las cookies de origen se envían solo al servidor que las configura, una página web puede contener imágenes u otros componentes almacenados en servidores en otros dominios (como banners publicitarios). Las cookies que se envían a través de estos componentes de terceros se denominan cookies de terceros y se utilizan principalmente para publicidad y seguimiento en la web.

Las cookies se inventaron para resolver el problema "cómo recordar información sobre el usuario":

• Cuando un usuario visita una página web, su nombre puede almacenarse en una cookie.
• La próxima vez que el usuario visite la página, las cookies que pertenecen a la página se agregarán a la solicitud. De esta forma, el servidor obtiene los datos necesarios para "recordar" información sobre los usuarios.

Ejemplo de GitHubGist

Como resumen,

• localStorage persiste en diferentes pestañas o ventanas, e incluso si cerramos el navegador, de acuerdo con la política de seguridad del dominio y las opciones del usuario sobre el límite de cuota.
• El objeto sessionStorage no persiste si cerramos la pestaña (contexto de navegación de nivel superior) ya que no existe si navegamos a través de otra pestaña o ventana.
• El almacenamiento web (sesión, local) nos permite guardar una gran cantidad de pares clave / valor y mucho texto, algo imposible de hacer a través de cookies.
• Las cookies que se utilizan para acciones delicadas solo deben tener una vida útil corta.
• Cookies utilizadas principalmente para publicidad y seguimiento en la web. Consulte, por ejemplo, los tipos de cookies que utiliza Google .
• Las cookies se envían con cada solicitud, por lo que pueden empeorar el rendimiento (especialmente para las conexiones de datos móviles). Las API modernas para el almacenamiento del cliente son la API de almacenamiento web (localStorage y sessionStorage) e IndexedDB.

Almacenamiento local :

• El almacenamiento web puede verse de manera simple como una mejora en las cookies, proporcionando una capacidad de almacenamiento mucho mayor. El tamaño disponible es de 5 MB, que tiene mucho más espacio para trabajar que una cookie típica de 4KB.

• Los datos no se envían de vuelta al servidor para cada solicitud HTTP (HTML, imágenes, JavaScript, CSS, etc.), lo que reduce la cantidad de tráfico entre el cliente y el servidor.

• Los datos almacenados en localStorage persisten hasta que se eliminen explícitamente. Los cambios realizados se guardan y están disponibles para todas las visitas actuales y futuras al sitio.

• Funciona en la política del mismo origen. Por lo tanto, los datos almacenados solo estarán disponibles en el mismo origen.

Galletas:

• Podemos establecer el tiempo de caducidad de cada cookie.

• El límite de 4K es para toda la cookie, incluido el nombre, el valor, la fecha de caducidad, etc. Para admitir la mayoría de los navegadores, mantenga el nombre por debajo de 4000 bytes y el tamaño total de la cookie por debajo de 4093 bytes.

• Los datos se envían de vuelta al servidor para cada solicitud HTTP (HTML, imágenes, JavaScript, CSS, etc.), lo que aumenta la cantidad de tráfico entre el cliente y el servidor.

sessionStorage:

• Es similar a localStorage.

• Los cambios solo están disponibles por ventana (o pestaña en navegadores como Chrome y Firefox). Los cambios realizados se guardan y están disponibles para la página actual, así como para futuras visitas al sitio en la misma ventana. Una vez que se cierra la ventana, se elimina el almacenamiento. Los datos están disponibles solo dentro de la ventana / pestaña en la que se configuró.

• Los datos no son persistentes, es decir, se perderán una vez que se cierre la ventana / pestaña. Al igual que localStorage, funciona en la política del mismo origen. Por lo tanto, los datos almacenados solo estarán disponibles en el mismo origen.

Aquí hay una revisión rápida y con una comprensión simple y rápida

del profesor Beau Carnes de freecodecamp