asp.net - true - url rewrite server variables
UrlRewriting.Net Module+IIS7 equivale a Page.User== null? (3)
He usado el módulo UrlRewriting.Net durante un par de años sin problemas en Windows XP y Windows 2003. Hace poco actualicé mi PC hogareña a Windows 7 y comencé a desarrollar un nuevo sitio web.
El plan era usar extensiones .html y volver a escribirlas en sus contrapartes .aspx utilizando el módulo UrlRewriting.Net. Todo funciona a la perfección en VWD 2008 , pero cuando intento ejecutarlo a través de IIS7, es una historia diferente.
Cuando intento acceder a una página a través de la revisión .html, ya no puedo acceder a Page.User; sigue volviendo nulo. Si toco la página con su extensión .aspx, la página. El usuario está correctamente poblado. También debo mencionar que tengo un controlador LoginView en mi página maestra y que sufre los mismos síntomas: al acceder a través de la extensión .html, muestra la plantilla Anonyous; Al usar la extensión .aspx, muestra correctamente LoggedInTemplate. Supongo que los dos están relacionados.
[Nota: también probé URLs sin extensión y muestran el mismo problema]
La única manera de hacerlo funcionar es cambiar el grupo de aplicaciones a Clásico, lo que me obliga a agregar un controlador ddl ASP.Net para la extensión .html [de lo contrario, es manejado por el StaticFileHandler y aparece como un 404 error]. Sin embargo, me gustaría que mi aplicación web se ejecute correctamente para las personas sin tener que jugar con IIS.
Entonces me quedan varias preguntas:
- ¿Alguien tiene ideas de por qué Page.Usuario siempre es igual a null para .html => .aspx páginas reescritas?
- ¿Por qué funciona en VWD 2008, pero no en IIS7?
- ¿Qué cambió de IIS6 => IIS7 que podría haber causado esto?
- ¿Alguna otra idea sobre soluciones temporales?
[Nota: Acabo de probar una reescritura de .aspx => .aspx y no mostró el problema. No es realmente lo que quiero, pero pensé que debería mencionarlo]
Acaba de tener un gran avance con el módulo UrlRewriting.Net. Esto lo hace funcionar en modo integrado en IIS7:
<modules runAllManagedModulesForAllRequests="true">
Después de resolverlo hice una búsqueda en "runAllManagedModulesForAllRequests" y lo primero que apareció fue el blog de Scott Guthrie, que habla sobre usarlo para este propósito.
Otro enfoque que parece funcionar es eliminar el módulo de sesión y leerlo dejando la casilla de verificación "Invocar solo para peticiones a aplicaciones ASP.NET o controladores administrados" sin marcar. Se ve así en el archivo web.config:
<system.webServer>
<modules>
<remove name="Session" />
<add name="SessionManualAdd" type="System.Web.SessionState.SessionStateModule, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</modules>
</system.webServer>
Parece que el problema es que el módulo de sesión no se ejecuta para los archivos say ''* .htm'' cuando se usa HttpContext.RewritePath, pero al eliminar y leer el módulo de esta manera, se ejecuta el controlador de sesión para la solicitud.
Esta solución fue sugerida en el hilo a continuación. Desafortunadamente, Microsoft optó por no explicar completamente el razonamiento detrás de este comportamiento:
Microsoft incluyó una solución para este problema (al menos para las URL sin extensión) en el Service Pack 1 para Win7 y Windows Server 2008 R2: http://www.microsoft.com/download/en/details.aspx?id=5842
También disponible como revisión: http://support.microsoft.com/kb/980368
Después de aplicar este parche, las aplicaciones ASP.NET 4 pueden manejar las solicitudes de URL sin extensión. Por lo tanto, se ejecutarán los HttpModules administrados que se ejecutan antes de la ejecución del manejador. En algunos casos, los HttpModules pueden devolver errores para URLs sin extensión. Por ejemplo, un HttpModule que se escribió para esperar únicamente solicitudes .aspx ahora puede devolver errores cuando intenta acceder a la propiedad HttpContext.Session.
Después de aplicar SP1 o la revisión, no se necesitan cambios de web.config para que la sesión y las formas de autenticación funcionen para URL sin extensión reescritas a páginas / controladores de asp.net / etc.
No sé si esto arregla algo para reescribir en extensiones de archivos estáticos como .htm. Creo que es probable que no. Intentaría evitar establecer runAllManagedModulesForAllRequests = "true" en entornos de producción, porque agrega una sobrecarga innecesaria en las solicitudes de archivos estáticos.