state - spanish - comparación de formas de mantener el estado

state verb (8)

Con el uso creciente 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 página para navegar, el estado no es un problema (pero los datos persistentes del usuario deben usar las llamadas XML asíncronas).

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

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

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

Estos son los que puedo pensar en este momento:

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 que QueryString tiene un límite de longitud y que es bastante desagradable de ver. ;)

Pero, al diseñar una aplicación web, siempre estoy confundido sobre qué métodos usar para qué aplicación o qué métodos evitar.

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

Evite InProc si planea alojar su sitio web en un host barato y n alegre como webhost4life. He aprendido de la peor manera que debido a que sus sistemas están sobrecritos, reciclan las aplicaciones con mucha frecuencia, lo que hace que su sesión se pierda. Muy molesto.

Su sugerencia es usar StateServer, que está bien, excepto que tiene que serializar / deserializar la publicación eash de sesión. Amo 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.

Desearía saberlo antes de empezar ...

Saludos, Rob.

La seguridad también es un problema; los valores en la cadena de consulta o en los campos de formulario pueden cambiarse trivialmente por el usuario. La autenticación de usuario debe guardarse en una cookie cifrada o inviolable o en la sesión del lado del servidor. Hacer un seguimiento de los valores pasados en un formulario cuando un usuario completa un proceso, como un registro de sitio, bueno, que probablemente se pueda mantener en campos ocultos.

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

No se trata de una cuestión de qué usar y qué evitar, sino cuándo usarla. Cada uno tiene una circunstancia particular cuando es la mejor, y una circunstancia diferente cuando es la peor.

El factor decisivo es generalmente el tiempo de vida de los datos. El estado de la sesión vive más tiempo que los campos de formulario, y así sucesivamente.

Personalmente, dado que casi todo mi desarrollo web es en PHP, utilizo los manejadores de sesión de PHP.

Las sesiones son las más flexibles, en mi experiencia: normalmente son más rápidas que los accesos a bases de datos, y las cookies que generan mueren cuando el navegador se cierra (por defecto).

Si bien esta es una pregunta muy complicada de contestar, tengo algunas cosas rápidas en las que pienso cuando considero la implementación del estado.

El estado de 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 hacerlo justicia, debe estar vinculado a una máquina de estado del lado del servidor conteniendo 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: 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 de nuevo similar: es útil para ocultar campos que vinculan un formulario dado a algunos datos en el back-end (por ejemplo, "este usuario está editando el registro n. ° 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 la cookie.
El estado de la sesión (cualquiera de las formas en que describes) es excelente, ya que son infinitamente extensibles y pueden manejar cualquier cosa que el lenguaje de programación elegido pueda manejar. La primera advertencia es que debe haber una clave en la mano del cliente para vincular a ese cliente con 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 las cadenas de consulta si las cookies no están habilitadas.) La segunda advertencia es que debe tener en cuenta cómo está almacenando su estado ... ¿lo pondrá en una ¿base de datos? ¿Su marco web lo maneja completamente por usted? Una vez más, la mayoría de los frameworks web modernos sacan el trabajo de esto, y para que yo pueda implementar mi propia máquina de estado, necesito una muy buena razón ... de lo contrario, es probable que cree agujeros de seguridad y roturas de funcionalidad que han sido hash a lo largo del tiempo en cualquiera de los marcos maduros.

Así que supongo que no puedo imaginarme que no quiera usar el estado basado en sesiones para nada, sino para la razón más trivial.

Tenga cuidado con qué estado almacena el lado del cliente (cadenas de consulta, campos de formulario, cookies). Cualquier cosa relacionada con la seguridad no debe almacenarse en el lado del cliente, excepto tal vez un identificador de sesión si está razonablemente oscurecido y es difícil de adivinar. Hay demasiados sitios web que tienen configuraciones como "authenticated = true" y las almacenan en una cookie o cadena de consulta o campo de formulario oculto. Es trivial para un usuario eludir algo así. Recuerde que CUALQUIER entrada proveniente de un cliente podría haber sido manipulada y no debería ser confiable.

Cookies firmadas vinculadas a algún tipo de almacén de base de datos cuando necesita capturar datos. No hay ninguna razón para almacenar datos en el lado del cliente si tiene un back-end conectado; solo buscas problemas si este es un sitio web público.