Problema ScriptResource.axd - Acceso Denegado de javascript en sitios con frames

Estoy desarrollando una aplicacion que muestra en un iframe otra aplicacion que contiene controles calendar ajax. El problema es que no despliega el calendario y aparece el siguiente error :

Mensaje: Acceso denegado.
Línea: 5959
Carácter: 49
Código: 0
URI: http://192.200.4.248/NOMBRE_APLICACION/ScriptResource.axd?d=2TUSrXlGiZ-YhriQIxHvs2j2r3CD-1dxiNch9HtINJ1-xYqYmXVZ2MxqzBF9v_CRUg-thDlUW3uXGz_vysgmtwWzobIsUaqbRwJQzvcSjKo1&t=633093755470531249 

Ese o en lugar de ScriptResource.axd. El punto es que la solución está en usar unos archivos de scripts modificados directamente en nuestros ScriptManagers. Esto se hace de la siguiente manera (en cada página que tenga un ScriptManager):

    <asp:ScriptManager ID="ScriptManager1" runat="server" >

        <Scripts>

            <asp:ScriptReference Name="MicrosoftAjax.js" ScriptMode="Auto" Path="../Includes/MicrosoftAjax.js"/>

        </Scripts>

    </asp:ScriptManager>

Adjunto aquí el par de archivos requeridos (MicrosoftAjax.js y MicrosoftAjax.debug.js).


Referencia:
http://creeperionet.blogspot.com/2011/12/problema-acceso-denegado-de-javascript.html

ERROR ASP NET : The source file is different from when the module was built

A esto se le suele llamar Dessincronización de Código
"There is no source code available for the current location" Error que emite Visual Studio en medio del debuggueo. Se da porque se produce una desincronización entre los diferentes proyectos de una solución (entre otras razones). Si al aparecernos por primera vez le dimos en el boton "NO" Entonces Visual Studio guardará una referencia del proyecto problemático para ignorarlo las proximas veces que se debuggea, por lo que cada vez que queremos depurar ese código nos va a aparecer "There is no source code available for the current location" para deseperarnos. 

Para solventar esta situación damos clic derecho sobre la Solución (NO sobre el proyecto). En "Common Properties" vamos a "Debug Source Files" y una vez ahi borramos las entradas del proyecto problematico que se encuentren en la sección inferior de la pantalla de la derecha denominada "Do not look for these source files". Esto provocará que Visual Studio no ignore las entradas del proyecto y nos permita de debugguearlo. 

Finalmente mientras nos encontramos en las properties de la Solucion, Nos vamos "Configuration Properties" y dentro de esta a "Configuration" y nos aseguramos que el check "Build" de los proyectos este checkeado, lo cual le indicará a Visual Studio que estos proyectos tienen que compilarse cuando ejecutamos la solucion en modo de debuggeo. Damos clic en aceptar y Generamos. Ya con esto deberíamos tener sincronizado nuestro código y el error en cuestión debería dejar de rondar por nuestra solución.

Lo último es ir a las carpetas donde se generan las dll de los proyectos (en mi caso bussiness y data) y eliminar las carpetas bin y obj. Volver a generar el proyecto y listo.

Errores ASP.NET en web farms muy comunes - Validation of viewstate MAC failed

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