ASP.NET Session

Lo primero que debo decir es que si nuestra aplicación debe estar en la WEB, entonces empezamos con un reto interesante. Puesto que la web no tiene estado, cada vez que solicitamos una página a un servidor, esta debe crearse, el protocolo que se emplea en Internet es el HTTP y este protocolo no permite conservar información entre pagina y pagina.

Luego entonces necesitamos algún lugar donde almacenar datos, para que puedan ser recuperados cuando se requiera.

La plataforma ASP.NET nos ofrece la administración de espacios de memoria en el servidor, que son transparentes para el usuario, donde es posible almacenar la información que necesitemos, este servicio se denomina: State Managemen.

Aun que a decir verdad, no todo es miel sobre hojuelas, este mecanismo ofrece muchas ventajas, pero también nos presenta serios problemas debido a que la información de la sesión se almacena en la memoria del servidor. Este mecanismo es accesible para WebForms y para MVC.

Almacenar información en una sesión requiere acceder al objeto Session, por ejemplo:

Este objeto puede almacenar incluso otros objetos.
 

Identificador de la sesión

Cada sesión en asp.net tiene su propio ID, este identificador es lo único que se envía cuando nos comunicamos con un servidor. De esta forma cada vez que regresamos al servidor y tratamos de acceder a un dato que previamente colocamos en el objeto sesión, ASP.NET usa ese identificador para localizar los datos.

Modos:

El mecanismo puede tener 4 modos:

• InProc: Almacena la sesión en memoria. (Modo por default)
• StateServer: Almacena la sesión usando el ASPnet_state.exe
• SQLServer: Almacena al sesión en una base de datos.
• Custom: Emplea un proveedor de estado personalizado.

No es mi intención exponer cada uno de ellos, para eso hay muchos lugares en Internet, donde pueden ver con detalle la implementación.

Seguridad

El identificador de sesión es lo suficiente seguro para que no sea posible hacerle ingeniería inversa, sin embargo esto no quiere decir que debamos almacenar en la sesión información confidencial o que requiera algún nivel de seguridad, ya que la sesión se puede expirar incluso estando loguiado.

Por ejemplo creer que es posible relacionar la sesión con la autentificación en algún punto es un mito. Así que debemos imaginarnos la sesión como un cache de memoria personalizado.

Lo que es necesario validar durante el proceso de Logueo, es si la sesión ha sido inicializada.

 

Eventos

Podemos controlar el momento en que empieza y el momento en que termina una sesión, ya sea porque la sesión fue abandonada o expiro.

 

Velocidad

El más lento es el Custom, el más rápido es el InProc. La razón es simple, para acceder a la información solo debe buscar en la memoria del servidor.

 

Cookies

Cuando usamos la colección Session, se crea una cookie llamada ASP.NET_SessionId. Es importante hacer notar que si no usamos la colección no se inicializa la sesión, por lo que no se regresara ninguna cookie al browser.

Si el usuario se loguea se crea una segunda cookie llamada .ASPXAUTH

Como se comento previamente, la información de la sesión no esta ligada de ninguna manera con el logueo.

Esta situación presenta un problema potencial que un Hacker puede aprovechar, y obtener acceso a la información de otro usuario. Aun que este tema se sale del alcance del post, por lo que en un próximo post hablare del tema.

 

Ser o no Ser

Es obvio pensar que a pesar de que nuestra sesión se encuentra en la memoria del servidor, y que es rápido acceder a ella, representa un consumo de recursos, que se debe realizar inteligentemente.

No es recomendable que todas las páginas de nuestro sitio usen la sesión; solo si es necesario para dicha página, por lo que se recomienda activar y desactivar la sesión según sea necesario, en cada página. Esto se puede llevar a cabo con las directivas de página:

<%@ Page EnableSessionState ="False"  %>
 
Almacenar el ID de la sesión

Si por alguna razón necesitamos almacenar ese ID, será necesario que usemos la colección Session, para que podamos acceder al identificador que se le asigno:

Este método puede ser llamado desde el Global.asax al momento que se inicia la sesión:

El poder del código solo es completo, si tenemos el conocimiento de como usarlo.