comparación de formas de mantener el estado

https://stackoverflow.com/questions/95655

state

01-07-2019
|

Pregunta

Hay varias formas de mantener el estado del usuario en el desarrollo web.

Estos son los que se me ocurren ahora mismo:

Cadena de consulta
Galletas
Métodos de formulario (obtener y publicar)
Viewstate (solo ASP.NET, supongo)
Sesión (servidor web InProc)
Sesión (servidor web dedicado)
Sesión (base de datos)
Persistencia local (Google Gears) (gracias Steve Moyer) etc.

Sé que cada método tiene sus propias ventajas y desventajas, como que las cookies no son seguras y QueryString tiene un límite de longitud y es simplemente feo a la vista.;)

Pero, cuando diseño una aplicación web, siempre estoy confundido en cuanto a qué métodos usar para qué aplicación o qué métodos evitar.

Lo que me gustaría saber es qué método(s) utiliza generalmente y recomendaría o, lo que es más interesante, ¿cuál de estos métodos le gustaría evitar en determinados escenarios y por qué?

Solución

Si bien esta es una pregunta muy complicada de responder, tengo algunas cosas breves en las que pienso cuando considero el estado de implementación.

El estado de la cadena de consulta solo es útil para las tareas más básicas, por ejemplo, mantener la posición de un usuario dentro de un asistente, tal vez, o proporcionar una ruta para redirigir al usuario después de completar una tarea determinada (por ejemplo, iniciar sesión).De lo contrario, el estado de la cadena de consulta es terriblemente inseguro, difícil de implementar y, para hacerle justicia, debe estar vinculado a alguna máquina de estado del lado del servidor que contenga una clave para vincular al cliente al estado mantenido del servidor para ese cliente.
El estado de las cookies es más o menos el mismo: simplemente es más elegante que el estado de la cadena de consulta.Pero todavía se mantiene totalmente en el lado del cliente a menos que los datos en la cookie sean una clave para vincular al cliente a alguna máquina de estado del lado del servidor.
El estado del método de formulario es nuevamente similar: es útil para ocultar campos que vinculan un formulario determinado con algunos datos en el back-end (por ejemplo, "este usuario está editando el registro #512, por lo que el formulario contendrá una entrada oculta con el valor 512").No es útil para mucho más y, nuevamente, es solo otra implementación de la misma idea detrás de la cadena de consulta y el estado de las cookies.
El estado de sesión (cualquiera de las formas que usted describe) es excelente, ya que es infinitamente extensible y puede manejar cualquier cosa que el lenguaje de programación elegido pueda manejar.La primera advertencia es que es necesario que haya una clave en la mano del cliente para vincularlo a su estado almacenado en el servidor;Aquí es donde la mayoría de los marcos web proporcionan al cliente una clave basada en cookies o en una cadena de consulta.(Casi todos los modernos usan cookies, pero recurren a cadenas de consulta si las cookies no están habilitadas). La segunda advertencia es que debes pensar un poco en cómo almacenas tu estado...¿Lo pondrás en una base de datos?¿Su marco web lo maneja completamente por usted?Nuevamente, la mayoría de los marcos web modernos eliminan el trabajo de esto y, para poder implementar mi propia máquina de estados, necesito un muy buena razón...de lo contrario, es probable que cree agujeros de seguridad y roturas de funcionalidad que se han solucionado con el tiempo en cualquiera de los marcos maduros.

Así que supongo que no puedo imaginarme no querer usar el estado basado en sesión por nada que no sea la razón más trivial.

Otros consejos

La seguridad también es un problema;El usuario puede cambiar trivialmente los valores en la cadena de consulta o en los campos del formulario.La autenticación del usuario debe guardarse en una cookie cifrada o a prueba de manipulaciones o en la sesión del lado del servidor.Realizar un seguimiento de los valores pasados en un formulario a medida que un usuario completa un proceso, como un registro en un sitio, probablemente se pueda mantener en campos de formulario ocultos.

Sin embargo, lo bueno (y a veces peligroso) de la cadena de consulta es que cualquiera que haga clic en un enlace puede detectar el estado.Como se mencionó anteriormente, esto es peligroso si le otorga al usuario alguna autorización que no debería tener.Sin embargo, es bueno mostrarles a tus amigos algo que encontraste en el sitio.

Con el uso cada vez mayor de la Web 2.0, creo que faltan dos métodos importantes en su lista:

8 aplicaciones AJAX: dado que la página no se recarga y no hay navegación de página a página, el estado no es un problema (pero los datos persistentes del usuario deben usar llamadas XML asincrónicas).

9 Persistencia local: las aplicaciones basadas en navegador pueden conservar sus datos de usuario y su estado en el disco duro local utilizando bibliotecas como Google Gears.

En cuanto a cuál es mejor, creo que todos tienen su lugar, pero el método Query String es problemático para los motores de búsqueda.

Personalmente, dado que casi todo mi desarrollo web se realiza en PHP, utilizo los controladores de sesión de PHP.

Las sesiones son las más flexibles, en mi experiencia:normalmente son más rápidos que los accesos a la base de datos y las cookies que generan mueren cuando se cierra el navegador (de forma predeterminada).

Evite InProc si planea alojar su sitio web en un host económico y alegre como webhost4life.Aprendí por las malas que debido a que sus sistemas tienen una suscripción excesiva, reciclan las aplicaciones. muy con frecuencia lo que hace que su sesión se pierda.Muy molesto.

Su sugerencia es utilizar StateServer, lo cual está bien, excepto que debe serializar/deserializar la sesión fácilmente.Me encantan los objetos y mi aplicación web está llena de ellos.Me preocupa el rendimiento al cambiar a StateServer.Necesito refactorizar para poner solo las cosas que realmente necesito en la sesión.

Ojalá lo supiera antes de empezar...

Saludos, Rob.

Tenga cuidado con el estado en el que almacena el lado del cliente (cadenas de consulta, campos de formulario, cookies).Todo lo relacionado con la seguridad no debe almacenarse en el lado del cliente, excepto tal vez un identificador de sesión si está razonablemente oculto y es difícil de adivinar.Hay demasiados sitios web que tienen configuraciones como "autenticado = verdadero" y las almacenan en una cookie o cadena de consulta o campo de formulario oculto.Es trivial para un usuario pasar por alto algo así.Recuerde que CUALQUIER entrada proveniente de un cliente podría haber sido manipulada y no se debe confiar en ella.

Cookies firmadas vinculado a algún tipo de almacén de base de datos cuando necesita obtener datos.No hay razón para almacenar datos en el lado del cliente si tiene un back-end conectado;solo está buscando problemas si se trata de un sitio web público.

No se trata tanto de qué usar y qué evitar, sino de cuándo usar cuál.Cada uno tiene circunstancias particulares cuando es lo mejor y una circunstancia diferente cuando es lo peor.

El factor decisivo generalmente es la vida útil de los datos.El estado de la sesión dura más que los campos del formulario, etc.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow