viernes, 21 de marzo de 2014

Roles para autorizaciones en el sistema.

Cuando un servicio comprueba la autorización de un usuario para ejecutar una acción utilizando roles suelo encontrarme con la siguiente implementación:

Public Enum Rol

ConsultorModulo1

ConsultorModulo2

OperadorModulo1

OperadorModulo2

Administrador

End Enum



function DoAction()

{

Rol allowedRoles[] = [OperadorModulo1, Administrador];

if (user.hasAnyRoleIn(allowedRoles))

{

DoAction();

}

else

{

throw new SecurityException("Permisos insuficientes");

}

}
  • ConsultorModuloX es un rol que permite consultar información pero no modificarla para un módulo del sistema en concreto.
  • OperadorModuloX es un rol que permite la modificación de información para un módulo del sistema en concreto.
  • Administrador es un rol que permite la totalidad de las acciones en el sistema.

No me gusta porque tenemos que encontrar coincidencias de items entre 2 conjuntos (roles que tiene el usuario y roles permitidos para la acción pertinente). Quedaría más eficiente y bonito si encontramos la manera de poder combinar varios roles en una sola variable y comprobar rápidamente si el usuario tiene asignado alguno (o varios o todos) de los roles necesarios.

martes, 11 de marzo de 2014

Resolver funcionalidades transversales sin Programación Orientada a Aspectos.

A mi me encanta la Programación Orientada a Aspectos (AOP). De hecho, la he aplicado exitósamente para gestionar la seguridad y el registro de trazas en varias aplicaciones utilizando mi librería AOP favorita en su version gratuita: PostSharp. Esta librería se encarga de inyectar el código de los aspectos en los ensamblados (Compile-Time Weaving) por lo que, al no funcionar sobre objetos virtuales, clases proxy y cosas por el estilo, no sufre de la problemática de otros frameworks AOP que obligan a limitar las formas de declarar las clases.

AOP es la mejor manera de gestionar y estructurar las funcionalidades transversales (cross-cutting concerns) de una aplicación; desgraciadamente está muy poco extendido y se está haciendo difícil adoptar estas tecnologías por parte del 'mainstream' del desarrollo de software (al menos en esta España garbancera).

Cuando un jefazo ignorante no me permite utilizar AOP para las funcionalidades transversales tengo un plan B que funciona a las mil maravillas: Usar un patrón decorador y construir una cadena de responsabilidades con la inyección de dependencias.


lunes, 10 de marzo de 2014

Arquitecturas débilmente acopladas.

Conseguir una arquitectura cuyos módulos tienen un acoplamiento débil no consiste sólo en crear una interfaz por cada clase existente y consumirla. Voy a intentar reproducir el proceso mental que yo sigo para llegar a este objetivo. Espero que esto sirva, a futuros lectores, para ayudarles a "cambiar el chip" a la hora de diseñar los módulos de un sistema de información.