¿Cómo se mantienen los datos de sesión?
Por el momento existen básicamente dos formas de mantener el estado de una sesión en ASP .NET.
La primera de ellas consiste en utilizar cookies http. Una cookie es un fichero que se almacena en el disco duro del cliente y puede ser recuperado por el servidor en cada visita posterior. Las cookies se utilizan en este caso para almacenar los datos necesarios que identifican a la sesión y este es el mecanismo utilizado por defecto en ASP .NET.
La segunda forma consiste en redirigir las solicitudes recibidas a una dirección que contiene el identificador de sesión incrustado en la URL. Para activar este segundo mecanismo en ASP .NET hay que establecer el atributo cookieless del elemento sessionState al valor true en el fichero web.config.
<?xml version="1.0" encoding="utf-8" ?/> <configuration/> <system.web> ... <sessionState cookieless="true" timeout="20" /> ... </system.web> </configuration/>
En aplicaciones web, una vez escogido el método a utilizar, no deberíamos preocuparnos de nada más, ya que tanto el servidor como el navegador del cliente se encargarán de gestionar las sesiones de manera automática. El primer mecanismo (el mecanismo por defecto) es el más recomendable y sólo deberíamos tener que cambiarlo en el caso de que necesitemos compatibilizar nuestra aplicación con navegadores que no acepten cookies o que las tengan desactivadas.
¿Y qué pasa con los servicios web?
El uso de sesiones ASP .NET para los métodos de un servicio web se encuentra desactivado de forma predeterminada. Para habilitarlo hay que añadir la propiedad EnableSession al atributo WebMethod de cada método de la siguiente forma:
[WebMethod (EnableSession=true)] public void MiMetodo () { ... }
Una vez hecho esto el método web al que lo hayamos aplicado tendrá acceso al objeto Session de .NET. Sin embargo, el correcto funcionamiento de la sesión depende del cliente ya que este debe aceptar cookies http (si se está utilizando el primer mecanismo de mantenimiento de sesión) o debe ser capaz de redirigir sus solicitudes a las direcciones modificadas con el identificador de sesión incrustado (en caso de que se esté utilizando el segundo sistema).
Puesto que el usuario deberá escribir código adicional en el cliente, que no existe un mecanismo estándar para manejar sesiones y que los servicios web están concebidos como stateless (sin estado), no es muy recomendable el uso de este tipo de sesiones en servicios web.
Una forma de emular la sesión de manera que el servicio sea compatible con todos los clientes sería:
- Haciendo que los métodos de nuestro servicio web devuelvan un objeto (nuestro objeto de sesión personalizado) con todos los datos que necesitemos sobre el estado actual.
- Creando los métodos web de manera que reciban nuestro objeto de sesión personalizado como parámetro.
[WebMethod ()]
public MiObjetoDeSesion MiMetodo (MiObjetoDeSesion miSesion) {
...
}
