¿Cuál es la diferencia entre localStorage, sessionStorage, sesión y cookies?

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

En todos los casos, estos mecanismos de almacenamiento serán específicos de un navegador individual en una computadora/dispositivo individual. Cualquier requisito para almacenar datos de forma continua entre sesiones deberá involucrar al lado del servidor de aplicaciones, probablemente utilizando una base de datos, pero posiblemente XML o un archivo de texto/CSV.

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

Almacenamiento local y almacenamiento de sesión

localStorage y sessionStorage son API relativamente nuevas (es decir, 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 sugiere el nombre) solo está disponible durante la sesión del navegador (y se elimina cuando se cierra la pestaña o ventana); sin embargo, sobrevive a las recargas de la página (fuente de la guía de almacenamiento DOM - Mozilla Developer Network ).

Claramente, si los datos que está almacenando deben estar disponibles de forma continua, entonces 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 conservar datos no confidenciales necesarios dentro de los scripts del cliente entre páginas (por ejemplo: preferencias, puntuaciones 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 se aplica a las cookies, que pueden ser manipuladas trivialmente por el usuario y los datos también se pueden leer en texto sin formato, por lo que si desea almacenar datos confidenciales, entonces la sesión es realmente su única opción. Si no utiliza SSL, la información de las cookies también puede interceptarse en tránsito, especialmente en una red wifi abierta.

En el lado positivo, las cookies pueden tener un grado de protección aplicado contra riesgos de seguridad como Cross-Site Scripting (XSS)/inyección de scripts al establecer un indicador de solo HTTP, lo que significa que los navegadores modernos (compatibles) impedirán el acceso a las cookies y valores desde JavaScript ( esto también impedirá que su 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 ha iniciado sesión; si tiene una copia de esa cookie, entonces, para 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 funcionalidades que el usuario.

Como las cookies se utilizan con 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 la página original, cualquier solicitud Ajax posterior, todas las imágenes, hojas de estilo, scripts y fuentes. Por este motivo, no se deben utilizar cookies para almacenar grandes cantidades de información. El navegador también puede imponer límites al tamaño de la información que se puede almacenar en las cookies. Normalmente, las cookies se utilizan 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.

Almacenamiento local frente a almacenamiento de sesión frente a 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 leerlos), pero no objetos ni matrices. (Es posible serializarlos en JSON para almacenarlos utilizando las API). El almacenamiento de sesión generalmente le permitirá almacenar cualquier primitivo u objeto admitido por 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 en 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 vencimiento variable (se renovarán cada vez que el usuario los visite) y, dependiendo de su servidor/marco, los datos se almacenarán durante el proceso (lo que significa que los datos se perderán si el servidor web falla o se reinicia) o externamente en un servidor estatal o una base de datos. Esto también es necesario cuando se utiliza una granja 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 por naturaleza.

La desventaja obvia de los datos del lado del servidor es la escalabilidad: se requieren recursos del servidor para cada usuario durante la duración de la sesión, y todos los datos necesarios del lado del cliente deben 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 consumidos por sesiones abandonadas. Por lo tanto, al utilizar datos de sesión, debe tener en cuenta la posibilidad de que los datos hayan caducado 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 desarrolladores/marcos web utilizan entradas HTML ocultas para conservar los datos de una página de un formulario a otra para evitar la caducidad de la sesión.

El almacenamiento local, el almacenamiento de sesión y las cookies están sujetos a reglas del "mismo origen", lo que significa que los navegadores deben impedir el acceso a los datos, excepto al dominio que configuró la información para empezar.

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

Nov 08 '2013 22:11 pwdst