Sospecho que ha caído en la trampa que todos hacemos, al creer que el atributo de roles restringe la visibilidad de los nodos. No lo hace, en realidad amplía la visibilidad. Todas las restricciones se realizan con la sección estándar en web.config.
Texto completo abajo es del post original en https://web.archive.org/web/20130408064047/http://ipona.com/asp-net-site-maps-security-trimming-and-roles/)
Ésta es una de las preguntas más frecuentes y parece una constante fuente de confusión para todo el mundo, como lo fue para mí cuando leí por primera vez sobre él. ASP.NET SiteMap permite que una estructura de navegación se defina como un conjunto de elementos XML, que son perfectos para describir una jerarquía de elementos de menú. Estos elementos XML son un elemento siteMapNode, que tiene un rol de atributo. Parece obvio que esto define los roles que pueden ver este elemento, pero lo obvio es, de hecho, incorrecto. Aquí está el hecho más importante sobre los mapas del sitio:
El atributo de roles no restringe la visibilidad de un nodo.
Eso debería ser lo suficientemente claro, aunque parezca incorrecto. Así es como funciona. Todas las restricciones a las páginas se manejan mediante autorización. Puede hacerlo en la base web.config o en los archivos web.config de las carpetas. Por ejemplo, suponga que hay una carpeta Admin, debajo de la cual se guardan todas las páginas de administración. Solo desea que estas páginas sean accesibles para los usuarios dentro de la función de administrador.Entonces configuraría su autorización, así:
<location path="Admin">
<system.web>
<authorization>
<allow roles="Admin" />
<deny users="*" />
</authorization>
</system.web>
</location>
La carpeta Admin puede ahora acceder ya no por cualquier persona que no está en la función de administración; si no está en la función de administrador e intenta navegar a una página en la carpeta de administración, ya sea a través de un enlace en otra página o escribiendo la URL directamente en el navegador, se le redirigirá a la página de inicio de sesión. Puede tener múltiples elementos de ubicación en su web.config, para diferentes carpetas o incluso archivos individuales; de hecho, si tiene un sitio restrictivo, puede abrir explícitamente ciertas páginas, como la página de inicio de sesión; es difícil iniciar sesión en un sitio cuando no tiene autorización para acceder a la página de inicio de sesión. Si prefiere no saturar su base web.config, puede crear un archivo web.config en la carpeta Admin con las mismas reglas; no necesitará el elemento de ubicación ya que la configuración se aplica a la carpeta actual.
Así que esa es la autorización; el acceso a las páginas está bloqueado. Ahora consideremos la navegación. El marco de navegación ASP.NET respeta la autorización, pero solo si configura el recorte de seguridad en el proveedor, que no está configurado de manera predeterminada. Esto significa que es necesario agregar la configuración del mapa del sitio para web.config:
<siteMap enabled="true" defaultProvider="AspXmlSiteMapProvider">
<providers>
<clear />
<add name="AspXmlSiteMapProvider" securityTrimmingEnabled="true"
type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
siteMapFile="web.sitemap"/>
</providers>
</siteMap>
mayor parte de esta se configura en el nivel de la máquina cuando se instala ASP.NET, pero fundamentalmente el valor securityTrimmingEnabled se establece en false por defecto . Lo que hace arriba borra la configuración existente y agrega una nueva entrada con el atributo establecido en verdadero. En esta etapa, el marco de navegación ahora respetará las reglas de autorización, por lo que los elementos del menú no se mostrarán si el usuario no tiene autorización para ese artículo; no importa si usa un menú o TreeView para mostrar los elementos del menú, la parte crucial es usar SiteMapDataSource (o la API Sitemap si está compilando el menú manualmente). Si tiene un proveedor de mapas de sitio personalizado, como uno impulsado por la base de datos (como este en MSDN), puede que tenga que hacer su propia comprobación de seguridad, pero depende de la clase base de la que herede. Esa es otra historia para otra publicación.
Entonces, si no necesita modificar los elementos del mapa del sitio, ¿para qué sirve el atributo de roles? Bueno, esto funciona de la manera opuesta que probablemente esperas, al abrir la visibilidad del nodo, mostrar el nodo si el usuario está en el rol indicado incluso si no tienen autorización para acceder a la página en sí (porque la regla de autorización los restringe de acceder a ella). ¿Por qué harías esto? Bueno, debes entender cómo funciona el recorte de seguridad. Al decidir si un usuario puede ver un nodo, se verifican tanto la autorización como los permisos del archivo físico; si cualquiera falla, entonces el nodo se considera inaccesible. Hay dos momentos muy comunes cuando las comprobaciones de archivos físicos fallan:
- La URL no es local. Si el archivo no existe localmente, entonces no se puede verificar.
- No hay una URL. El nodo podría ser solo un nodo contenedor, con páginas secundarias pero sin página en sí.
En ambos casos, las comprobaciones de archivos físicos fallan por lo que no se mostrará el nodo. Por lo tanto, puede necesitar abrir la visibilidad del nodo. Por ejemplo, considere lo siguiente:
<siteMapNode title="Admin" roles="Admin">
<siteMapNode url="~/Admin/membership_CreateMember.aspx" title="Create User" />
<siteMapNode url="~/Admin/membership_GetUsers.aspx" title="View Users" />
<siteMapNode url="~/Admin/roleManager_CreateRole.aspx" title="Create Role" />
<siteMapNode url="~/Admin/roleManager_AddUserToRole.aspx" title="Add User to Role" />
</siteMapNode>
Aquí el nodo de administración no tiene una página física, es puramente para permitir la organización de los elementos de administración en su propio submenú. Sin el atributo de roles adicionales, el nodo y los hijos no aparecerían, pero roles = "Admin" establece que el nodo también se debe mostrar a los usuarios dentro de la función de administración, incluso si falla la comprobación de seguridad. No necesitamos el atributo en los nodos secundarios porque tienen páginas físicas, por lo que las verificaciones de archivos tendrán éxito.
Por lo tanto, es bastante sencillo si recuerda las reglas: las restricciones de seguridad
- Configuración de las páginas con la autorización de web.config.
- Redefina el proveedor del mapa del sitio, habilitando el recorte de seguridad .
- Agregue el atributo de roles a los nodos del mapa del sitio para ampliar la visibilidad .
Gracias. Encontré el pequeño error que estaba presentando. En mi elemento estaba usando '?' en lugar de '*'. Una vez que cambié eso, todo comenzó a funcionar correctamente. –
+1 para una gran publicación de blog que lo explica muy bien. – Sprintstar
gran enlace, nunca hubiera sabido que funciona de esta manera. –