:::: MENU ::::

La evolución: Local Storage & Session Storage

¡Hola programadores!
Como ya dije hace un tiempo, me niego a poner el cartelito de las cookies, pero bueno, luego en la práctica no es para nada necesario y en realidad… si os quedáis hasta abajo, veréis que en este tema, no influye.

Sea como fuere, no vengo a hablar de esto, si no de la evolución de la web. Y es que Local Storage y Session Storage (aunque personalmente desprecio completamente la segunda), nos permite ver hacia dónde apunta el desarrollo web, y es que estas no pueden ser accedidas por el servidor.

¿Qué significa esto?
Muy fácil: así como las cookies son accedidas por el servidor, normalmente, ya que se mandan junto a las cabeceras, para controlar el logueo de los usuarios; el Local Storage, que no es más que un objeto en JavaScript en el cual podemos guardar strings, u objetos (si contamos que podemos hacer uso de funciones como stringify o parse de JSON), que es almacenado en el navegador al igual que las cookies, no puede ser leído ni se envía mediante las cabeceras al servidor.
Esto último implica que tenemos que usar JavaScript sí o sí para poder interactuar con dichos objetos, de esa forma esto marca una tendencia hacia tener un cliente que muestra la web a base de pequeños datos, como pueden ser objetos JSON, XML (que ya va quedando obsoleto…) u otros métodos como la utilización de node.js, en lugar de que sea el servidor que pre-procese el HTML añadiéndole el contenido.
Obviamente con cookies ya se podía hacer esto, permitiendo además que el servidor leyera directamente de ellas la información que necesitaba para identificar al usuario, pero que las nuevas tecnologías como es LocalStorage apunten a evitarlo, implica y marca una tendencia a seguir.

¿Es mejor?
En caso de usar node.js/websockets, no nos va a afectar, puesto que podíamos leer las cookies desde JavaScript con el objeto docmuent.cookie, pero eso reduce en un pequeñísimo porcentaje la carga de la web, puesto que no tiene que enviar las cookies mediante las cabeceras.
Si usamos PHP puro, podemos olvidarnos, pero lo que sí que podemos hacer, al igual que antes (solo que ahora creando la necesidad implícita de transferir los tokens de las sesiones mediante el método get o post en una petición ajax, y siendo esto una práctica que utilizan servicios como Habbo Hotel para cargar, por ejemplo, las notícias) es enviar con ajax, como he mencionado anteriormente, una petición al servidor, adjuntando también un token, y que este nos devuelva todos los datos necesarios para la web, que además serán colocados con JavaScript.
Con esto último, reduciremos considerablemente el tiempo de carga de nuestra web, o como mínimo el de repuesta del servidor, ya que una vez servido el HTML y los scripts por primera vez, no necesitaremos obtenerlo de nuevo para cambiar su contenido, puesto que podremos hacerlo con solo obtener objetos JSON (u otras maneras) y reemplazando el contenido de elementos por otros, como por ejemplo un campo de nombre de usuario.
No solo, además, podremos cambiar solo el contenido en cuanto a texto, sino que podremos también cambiar el HTML, implicando así que podremos cargar páginas distintas en una sola página, y gracias a funciones como ‘location.pathname.replace’, podremos incluso cambiar la dirección en la barra de direcciones, de forma que si un usuario copia un link al visualizar una foto y se lo pasa a otra persona, podremos cargar la foto directamente al cargar la página (como ya hace twitter o facebook).

Por supuesto, para proyectos pequeños en los cuales la carga del servidor no sea tan importante (ya que obviamente la diferencia será de milisegundos, y que si solo se ve una página será contraproducente), no necesitamos usar dicha nueva tecnología, que además de ser más tediosa y larga a la hora de desarrollar, también aumenta la carga en el navegador, mucho más que una simple página estática en HTML puro, de forma que si hacemos un pequeño blog o una web de empresa, con ni tan solo un millón de visitas mensual, no recomiendo hacerlo bajo ningún concepto.

Entonces… ¿Cookies o LocalStorage?
Fácil, como he aclarado en el párrafo anterior, según el tamaño del proyecto, cargar el cliente en exceso y/o si la carga del servidor no importa, usar LocalStorage es contraproducente. En cambio, si es un gran proyecto como Twitter o Facebook, entonces, usar el cliente como base para cargar toda la web puede ser la mejor opción. Por ende, yo usaría cookies si queremos tirar de servidor y LocalStorage si de JavaScript va la película.
A excepción de si usamos PHP, entonces usar LocalStorage no vale la pena del todo, de cualquier forma vamos a transferir los datos al servidor mediante cabeceras (ojo, si que nos puede servir para controlar qué datos le enviamos, y además, recordemos que si los datos son sensibles o solo se requieren para el funcionamiento temporal de la web, puede ser mejor usar LocalStorage).
Y sí, eso último que acabo de decir se hace posible con LocalStorage, pues este nos permitirá almacenar parámetros como el color de fondo que preferimos u otros detalles (incluso que pueden ser asignados por el servidor al iniciar sesión) y así no tener que cargarlos cada vez, reduciendo una petición al servidor por cambio/carga nueva de página.

Por ende, y contando que cada uno tiene sus pros y sus contras y que no nos vamos a saltar el cartelito de las cookies (puesto que este también es regulado por la famosa ‘ The Cookie Law’), va a depender del caso el hecho de usar uno u otro.

Para los que reclamen por la seguridad: ambos son IGUAL de seguros en cuanto a que el cliente los puede leer y modificar con tan solo la consola JavaScript, pero las cookies se enviarán al servidor en las cabeceras, mientras que el LocalStorage/SessionStorage permanece en el navegador si no lo enviamos nosotros con JavaScript.

Espero que os haya servido de ayuda esta pequeña reflexión.
¡Un saludo a todos!


Cookies VS Session en PHP

Si eres programador de PHP sabrás que existen cookies y session, y, seguramente, habrás usado ambas.
Para hacer una web “tonta”, o de prueba, o en la que simplemente te vayas a loggear tu y no la conozca nadie y no tengas nada interesante, ¿para qué usar cookies si es mucho más tedioso?
Pero bueno, quiero hacer este post para discutir sus ventajas, desventajas, etc.

Session
Las sesiones de PHP es un sistema que lleva incluido el cual crea una cookie en el navegador llamada PHPSESSID que contiene un código de 32 caracteres generados al azar, y luego crea una carpeta donde para cada sesión guarda un archivo que contiene todos los parámetros que guardes en los conocidos $_SESSION[‘algo’].
Sí, es tan cómodo como poner session_start(); y empezar a guardar datos en el usuario, y para desloguearle es tan sencillo como un simple session_destroy();.La cosa es que también podemos intentar robar sesiones a base de fuerza bruta u obteniendo la cookie del navegador (pero lo último es algo irremediable, si tenemos acceso al ordenador del usuario, da igual si son cookies, sesiones, etc. que si queremos robar la sesión, podemos). Incluso con un analizador de de protocolo de red podemos sacar las cookies muchas veces, si no entran con SSL está chupado, y si no tan fácil como usar nuestra amiga, la foquita malvada, y hacer un SLAAC attack, pero bueno, olvidemos eso peusto que pasa lo mismo con las cookies.

Cookies
Volviendo al debate entre Cookies y Session (puesto que en la anterior me he ido por los cerros de Úbeda hablándoos de la Foca), las Cookies nos ofrecen más posibilidades a los programadores para jugar. Básicamente podemos crear cookies de la duración que queramos, con el nombre que queramos, que funcionen en la carpeta que queramos y encima los que almacenan la información temporal son los usuarios y no nosotros. Aun así, no es recomendable leer la información de las cookies y basarse en ella. Si es algo que el usuario pueda editar desde la web (como por ejemplo, el primer paso de un registro de dos pasos, siempre verificando la información dada), entonces sí que podemos confiar en que si editan algo, no nos perjudicará, ya que como buenos programadores comprobaremos que todo lo almacenado en las cookies sea válido como en el confirmación del primer paso del registro ¿verdad? (si no ya sabéis, ahí tenéis unas vulnerabilidades que arreglar YA).
Una vez sabemos los fundamentos de las cookies, sabemos que si almacenamos el ID de un usuario pueden simplemente cambiarlo por otro ID, y así entrar por ejemplo en el ID 1 que será seguramente el creador/administrador de la web. Pero para solucionar eso lo que se hace es crear otra cookie con números, letras, otros caracteres o lo que sea generados al azar y muy largos (de 100 o más caracteres) y almacenarlos junto al usuario en la base de datos, de modo que si el ID y el código creado coincide con las cookies se permite que vea la web logueado. Y sí, con eso también se puede hacer fuerza bruta, pero a más caracteres, más seguridad y además nos permite a los programadores tener el sistema de seguridad que queramos.
La cosa de las cookies es que podemos personalizar la duración, le podemos dar algunos flags que “aumentan la seguridad”, poner la ruta que queramos, y en fin, tenemos más control sobre las sesiones, y al fin y al cabo, cada programador tiene su estilo.

En definitiva: yo opto por usar cookies, siempre que vayamos con cuidado, aun que me niego rotundamente a poner el cartelito de ‘esta web usa cookies’, es una obviedad que si te vas a loguear por narices vas a usar cookies, dudo que haya alguna web que con el navegador, el sistema operativo y la IP ya te permita loguearte, por que si no tu [email protected], padre, madre o lo que sea con el mismo ordenador vería tu cuenta, con lo cual, cookies always, ya sea por la sesión del PHP que crea una sola cookie, o por las cookies que cree una página personalizadas.

Y por último quiero pedir disculpas por haber estado tanto tiempo sin escribir nada, la verdad es que el tiempo no es algo que abunde, sobretodo cuando tienes pendientes 20mil trabajos de programación y 10 personas pidiéndote cada día por Skype cómo los llevas ejem. Y también os recuerdo que en mi canal estoy subiendo una serie de Minecraft (que no tiene nada que ver con informática, pero en mi canal hago lo que me da la gana, ¿no?) así que ya sabéis, si os gusta, ahí está :P

Buenas tardes y feliz fin de semana a todos :D