Y lo bueno (y lo malo) es que por ahora hay dos maneras de evitar esto: controlando las excepciones de acceso denegado por código (SPSecurity.CatchAccessDeniedException) o bien implementando un HttpModule como el siguiente:
using System; using System.Web; namespace MyNamespace { public class CustomAccessDenied : IHttpModule { public void Init(HttpApplication context) { context.EndRequest += ContextAcessDenied; } public void Dispose() { } static void ContextAcessDenied(object sender, EventArgs e) { try { var httpApp = sender as HttpApplication; if (httpApp != null) { var context = httpApp.Context; var httpUrl = context.Request.Url.ToString(); if (httpUrl.ToLower().Contains("/_layouts/accessdenied.aspx")) { HttpContext.Current.Server.ClearError(); HttpContext.Current.Response.Clear(); HttpContext.Current.Response.Redirect( "/Anonymous/Pages/CustomAccessDenied.aspx", false); } } } catch (Exception ex) { //... } } } }
Este HttpModule redirigiría las peticiones que han devuelto con URL '_layouts/accessdenied.aspx' a una página personalizada que debería estar en un subsitio anónimo de nuestra colección de sitios. Ello implica, sí, habilitar la disponibilidad de acceso anónimo en toda la colección.
Este HttpModule sería, de las dos soluciones, la menos intrusiva en el código de nuestro portal. Y que conste que no soy para nada partidario de hinchar los web apps de handlers y módulos, pero reconozco que en esta ocasión el requerimiento lo merece...
Edit: cuidado con la opción "Sign as a different user" del menú Welcome. Redirige a /_layouts/accessdenied.aspx?loginasanotheruser=true&Source=... Tenemos que modificar el HttpModule para que deje pasar estas peticiones.
0 comentarios:
Publicar un comentario