¿La sesión web es "mal diseño"? ¿Por qué?

13

el otro día estaba discutiendo con un colega y salió diciendo que usar la sesión del usuario en una aplicación web es simplemente incorrecto. Respondí que podría estar mal dependiendo de la información que esté almacenando, de lo contrario, ¿por qué debería un servicio de sesión web incluso proporcionado por Microsoft (estábamos hablando de ASP.NET)?

Él me respondió, una vez más, que incluso en la EM podrían responderme fácilmente que era un mal diseño. Y que él podría mostrarme algunos libros blancos que lo demuestran.

Lamentablemente ya no tengo oportunidad de contactar a este tipo, pero realmente me gustaría entender más sobre su punto de vista. ¿Alguien tiene información / puntos de vista sobre eso aquí?

web-applications

— abx78
fuente

2

El protocolo HTTP fue diseñado originalmente para ser "sin estado", de modo que todas las transacciones fueran singulares y se basaran en la información proporcionada. Las sesiones son una forma de evitar eso en algunos usos. Sin embargo, en la práctica, para muchos sitios web modernos, no puedo pensar en una forma simple de evitar las sesiones; Tal vez no soy lo suficientemente creativo.

— Katana314

@ Katana314 Almacenamiento de base de datos con cookies. Puede usar sesiones para obtener información muy básica, como identificar al usuario, pero muchas implementaciones de sesión (particularmente en Django, que hemos encontrado varias veces) tienen fallas que pueden crear condiciones de carrera con más datos transitorios cada vez que el mismo usuario solicita varias veces. se envían a la vez (como con llamadas AJAX)

— Izkata

2

El almacenamiento de la base de datos con cookies es solo una cuestión de alojar su sesión en una base de datos.

— Alan Shutko

11

No creo que haya querido decir "mal diseño" sino "mala práctica". En términos generales, una aplicación web debe ser tan apátrida como sea posible. Aunque, por ejemplo, es posible que necesite conocer la información del usuario para autorizar la visualización de la página, esa información podría guardarse en la máquina del cliente en forma de cookie y el servidor simplemente valida la información del usuario cada vez.

Eso sería ideal, pero no siempre puede contar con que el cliente pueda guardar cookies. Además, implica validar al usuario de forma apátrida, lo que potencialmente implica consultar información de la base de datos para una simple solicitud de página. Muchas veces es más sencillo guardar dicha información en la sesión.

Sin embargo, una vez que haya cruzado el Rubicón, muchos programadores se sienten tentados a guardar no solo la información de autenticación en la sesión, sino también muchas otras cosas. Este es un antipatrón y tiende a hacer que su aplicación web dependa en gran medida del estado, que es precisamente lo que se suponía que debía evitarse en primer lugar.

Algunos programadores se basarían en tecnología como Spring (si está utilizando Java) para desenredar lo que de otro modo sería un desastre de dependencias, pero argumentaría que eso solo hace que sea más fácil crear dependencias en lugar de eliminarlas. Dichas tecnologías deberían ayudar a su desarrollo, no hacer que su antipatrón sea un problema menor.

Por lo tanto, una buena regla general es que si puede escribir sin estado, probablemente sea una mejor idea hacerlo o corre el riesgo de caer en esta trampa. Obviamente, se encontrará con situaciones en las que esto es necesario, pero en términos generales, solo debe guardar información que de otro modo sería difícil de recuperar.

— Neil
fuente

1

but you can't always count on the client being able to save cookiesentonces AFAIK, tampoco puedes contar con sesiones. ¿No se utilizan cookies para identificar qué sesión pertenece a qué usuario, o existen otros métodos y ese es simplemente el más común?

— Izkata

La información de la sesión normalmente se guarda en el servidor para cada conexión de servidor / cliente, y esto se convirtió en una tendencia popular para los grandes sitios web que no podían confiar en que los usuarios tengan habilitadas las cookies. Hay opciones (y / o bibliotecas js) que obligan a guardar dicha información en la PC cliente (que se ha vuelto muy popular en los últimos tiempos), pero sin HTML 5, las cookies son la única forma de lograrlo. Que yo sepa, no hay otras formas de hacerlo.

— Neil

8

Creo que está confundiendo dos temas diferentes: 1) sesiones y 2) el modelo de página de los formularios web asp.net

Una sesión web es necesaria para la autenticación de un usuario. Idealmente, una sesión solo debe usarse para este propósito. No debe almacenar datos de usuario en una sesión (ya sea en el servidor, en una cookie o como lo hace asp.net/webforms: dentro de la página). Nadie debería decir que una sesión web es mala, sino almacenar datos de usuarioEn una sesión es una mala práctica. Los motivos para no almacenar datos de usuario en el servidor incluyen los mismos motivos para evitar variables globales. El almacenamiento de datos de usuario en cookies o en la página puede presentar problemas de seguridad. El uso del modelo de página de asp.net tampoco se adhiere a la naturaleza apátrida de la web. Puede hacer una búsqueda para obtener más información sobre por qué los formularios web son un mal diseño. Las sesiones, por otro lado, son una parte necesaria de las aplicaciones web.

— descifrador
fuente

"Las sesiones, por otro lado, son una parte necesaria de las aplicaciones web". No.

— masterxilo

6

Los controles y el estado de la sesión de almacenamiento en una página son esencialmente un truco. Es el caso de MS, una necesidad, ya que querían poder proporcionar un entorno de desarrollo en el que se pudieran diseñar páginas como se pueda en entornos winform.

MS se ha movido hacia la arquitectura MVC (última versión, MVC 4), que es más un retorno a lo que el protocolo debería ser: sin estado.

Hay situaciones en las que el estado de almacenamiento sigue siendo útil, pero debe entenderse que esta es la excepción y no la regla.

— Robbie Dee
fuente