Restricción de Accesos en ASP.NET 2.0

14 01 2008

El año pasado, nuestro equipo inicio el desarrollo de una aplicación para el control de volúmenes de obra. Iniccialmente planteamos usar totalmente técnologias Java (Struts 2, Hibernate). Despues del primer mes de desarollo por politicas de la empresa se cambio de lenguaje a C# con SQL server, asi que junto con mi equipo tuvimos que aprender la tecnología a golpe y porrazo, durante la marcha.

Como se podrán imaginar cometimos varios errores, por nuestro poco conocimiento .net. El viernes pasado reparé uno de los que más quejas y bugs ha causado es la restricción de accesos recursos segun el rol del usuario.

Restricción de accesos
En .NET 2.0 es posible restringir globalmente el acceso a un recurso (URL), colocando los privilegios de acceso en el Web.config. por ejemplo. si tenemos un sitio con la siguiente estructura

  • Default.aspx
  • /empleados/
    • DetalleEmpleado.aspx
  • /admin/
    • Default.aspx

Queremos restringir el acceso para que los empleados tengan acceso solo a consultar el detalle del empleado y los usuarios con rol administrador sean los unicos en acceder a /admin/Default.aspx se debe tener lo siguiente declarado en el Web.config

  1. <location path=“admin/Default.aspx”>
  2. <system.web>
  3. <authorization>
  4. <allow roles=“administradores”/>
  5. <deny users=“*”/>
  6. </authorization>
  7. </system.web>
  8. </location>
  9. <location path=“empleados/DetalleEmpleado.aspx”>
  10. <system.web>
  11. <authorization>
  12. <allow roles=“empleados”/>
  13. <deny users=“*”/>
  14. </authorization>
  15. </system.web>
  16. </location>

Con esto el framework solo permite el acceso a los usuarios perteneciente al rol especificado, niega el acceso a cualquier otro ()

  • El atributo users puede tener los siguientes wildcards
    • * indica cualquier usuario incluyendo el usuario anonimo
    • ? indica usuario anonimo

Ocultar opciones en menus y en barras de navegación

Ahora para ocultar los paths indicados en los locations anteriores, en las opciones de menu. se debe agregar lo siguiente en el web .config

  1. <system.web>
  2. <siteMap defaultProvider=“secureProvider” enabled=“true”>
  3. <providers>
  4. <add name=“secureProvider”
  5. description=“Default SiteMap provider.”
  6. type=“System.Web.XmlSiteMapProvider “
  7. siteMapFile=“Web.sitemap”
  8. securityTrimmingEnabled=“true”/>
  9. </providers>
  10. </siteMap>
  11. ..
  12. ..
  13. </system.web>

Lo mas importante es el atributo securityTrimmingEnabled con esto el XmlSiteMapProvider automaticamente oculta los paths no alcanzables para un usuario dado , tomando como referencia la configuración del web.config.

Nosotros pensabamos que la restriccion se hacia en base al atributo roles del elemento siteMapNode en el web.sitemap, pero ese atributo es tomado en cuenta solo para los nodos que no tienen una URL asociada, esto lo comprendimos despues de leer el post de Danny Chen , An overview of how securityTrimmingEnabled is supposed to work de implementar tantos remedios caseros para nuestros bugs , hasta implementamos un httpModule para filtrar las URLs, si tan solo la documentación fuera más clara y nosotros nos ubieramos detenido a aprender bien la tecnologia antes de hacer remedios caseros a la mexicana





Juguetes Nuevos- Microsft Enterprise library

30 07 2007

Microsft Enterprise library

El viernes pasado me heche el primer round con la Enterprise library, la cual provee varias funciones disque para facilitar el desarrollo de aplicaciones empresariales. cuando la encontré en codeplex, sonaba muy bien, pero despues de bajarla he instalarla comenzo a sacar las uñas. primero por las limitaciones de internet que tenemos por acá, no me fue posible ver los screen cast de microsoft, así que me chute toda la desimantación que encontré por alli. cheque los ejemplos, los compile y ejecute y todo funcionaba de maravilla pero cuando quise integrarlo a mi proyecto real, que me sale conque siempre no!

Could not load file or assembly ‘Microsoft.Practices.EnterpriseLibrary.Logging

Allí empezaron mis problemas, cheque el archivo de configuración pero solo vi sospechoso el PublicKey =null en la declaración de la referencia.El lunes encontré el blog de Tom Hollander Product manager de Microsoft Patterns & Practices, quien mejor que este muchacho para decirme que le pasa a mi proyecto. así que me chute su post sobre las incompatibilidades de la versión pre-compilada y la compilada de la librería. Al final todo se resumió a utilizar el configurador de la version compilada C:Archivos de programaMicrosoft Enterprise Library 3.1 – May 2007Bin