Errores ASP.NET en web farms muy comunes

Hay veces que tenemos una aplicacion web ASP.NET que está alojada en un Proveedor de Internet o ISP y se instala en una granja de servidores web o “WebFarm” que no es ni más ni menos que varios servidores en paralelo que actúan como si fuera uno solo por si se cae uno y responda a las peticiones web otro servidor de la granja de forma transparente al usuario. En esos casos a veces despues de entrar en un area privada de nuestra aplicacion web que usa variables de sesion inexplicablemente nos sale un error parecido a esto y nos dice que debemos tocar el Machine.config pero el servidor no es nuestro!:


Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.


Esto está muy bien para conseguir Redundancia y alta disponibilidad mediante los servicios de Clustering de Windows 2003 pero tiene una pega para nuestros compañeros los desarrolladores web. ¿Cual? Pues que cuando usamos variables de sesión en nuestra aplicación web , estas quedan almacenadas por defecto en el servidor web que estaba ejecutando la aplicación y si este cae por un fallo hardware o de comunicación por ejemplo entonces otro servidor web que no tiene tus variables de sesion recogerá las peticiones http a tu web y no sabrá quien eres si identificabas a tu visitante con un Session(“idusuario”) recogido por ejemplo al autentificarse en la web.


Para esto veo 2 soluciones posibles :


1- Poner esto en el web.config <pages enableViewStateMac=”false” /> como sugieren algunos ISP. Ojo, esto debe ponerse dentro de <system.web></system.web>
Esta propiedad tambien puede aplicarse a paginas web aspx individuales en la directiva <@Page %>  y por defecto suele ser false. Aqui teneis mas informacion sobre la propiedad en la MSDN. Para el que no lo sepa , esta directiva se usa para evitar la corrupxion o alteración de los datos conforme se envían a una pagina web.


2- Habilitar el estado de las sesiones en SQL Server. Al estar las sesiones en el servidor de base de datos, es independiente de que se caiga el servidor web, pues podrá recuperar las sesiones de una base de datos externa al servidor web. En este articulo podeis ver como configurar sql server para ello, pero tened en cuenta que debéis ser administradores del servidor y no servirá en un alojamiento compartido a no ser que seais “amigo” del propietario del servidor 🙂


http://support.microsoft.com/kb/317604/es


NOTA: Por defecto en el web config que se genera en Visual Studio el estado de sesion se guarda asi:

<sessionState

mode=”InProc”


stateCon蠌ectionString=”tcpip=127.0.0.1:42424″


sqlConnectio蚼String=”data source=127.0.0.1;Trusted_Connection=yes”

cookieless=”false”

timeout=”20″

/>

 


AVISO IMPORTANTE:


No olvideis nunca cuando paséis a produccion vuesrtas web asp.net generar los ensamblados en modo Release y no Debug y cambiar estas lineas en el web.config para que queden así


<compilation defaultLanguage=”vb” debug=”false” /> 


¿Acaso vais a depurar la aplicacion en el servidor web de desarrollo? Con esto no teneis que subir a bin el fichero .pdb que se genera en asp.nett 1.x sino solo los ensamblados .dll


<customErrors mode=”RemoteOnly” /> Para que los errores asp.net no aparezcan a usuarios que no estén en el servidor local y no puedan recopilar información para un ataque 😉


Saludos


Sergio


 


 

4 comentarios en “Errores ASP.NET en web farms muy comunes”

  1. Hola Sergio,

    quería matizar varias cosas de lo que has comentado.

    El error no indica modificar el machine.config, si no machineKey, que es algo que podemos cambiar en nuestro Web.config.

    El error no viene producido por la sesión, si no porque la clave para encriptar el ViewState no es el mismo de una máquina a otra, con la cuál, una encripta el ViewState y te lo envía pera al hacer un postback e ir a otra máquina no sabe desencriptar el ViewState.

    Para ello hay que coger todas las máquinas y para esa aplicación poner el mismo machineKey en todas en el Web.config, para que cuando una encripta, cualquier otra sepa desencriptar.

    Espero haber aclarado esto un poco más!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *