Ver Mensaje Individual
  #6  
Antiguo 16-11-2007
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Reputación: 25
Delphius Va camino a la fama
Hola Dec,
Veamos al problema de debemos partir en dos....
Lógica por un lado, lo visual por el otro.

El problema se soluciona de diferentes maneras. Como tu comentas.... una es ocultar las cosas dependiendo de los permisos que tiene.
Esta es la más común y considero que es la más simple. Creería que con eso no tienes problemas.

La cuestión de la lógica: Como registrar estos permisos... Bueno, en esto todavía estoy como en formación pero estaba pensando en conseguir algo parecido a lo que se conoce como matriz de perfiles.

Dicha matriz cuenta por el lado de las columnas cada perfil, y por el lado de las filas las funcionalidades. Por cada combinación válida entre P (Perfil) y F (funcionalidad) se marca la celda con una X.
Veamos algo así:

Código:

---- P1 --- P2 --- P3 ---
F1 - X  ---    --- X  ---
F2 -        X  ---    ---
Cada X es un permiso.

Si es necesario, debería contarse con un alguna función que determine ciertas posibles incongruencias... algunas especies de reglas que dicte el negocio.

Porqué te digo esto de la matriz, porque es posible que las asignaciones entre los perfiles y las funciones cambien. Y una manera de comprobar las posibilidades de armado de esta matriz es teniendo un conjunto de reglas que chequen las posibles combinaciones.

Ahora viene lo lindo... ¿Como representar esto en una DB?
Lo natural: Una tabla Perfiles, otra tabla Funciones (tu verías que campos serían necesarios). Esto permite hacer que la matriz se amplie si es necesario. Permitiendo modificar, añadir tantas funciones como perfiles sean necesarias.

El problema de los perfiles a los que te ves sometido: esta subclasificación puede resolverse de forma sencilla: en realidad le asignamos un nombre ficticio a dicho subperfil y lo hacemos pasar como si fuera un perfil en la tabla. Por ejemplo que P12 sea un subperfil de P1. Como en tu caso: Editor es un subperfil de Admin, y Administrador de Admin (por darle un nombre).

El problema en tu caso sería que hay una pequeña complicación, entre los mismos perfiles hay algunas funciones que no las cumple del toda un determinado usuario (o al menos eso entendí yo). Es decir que no siempre un usuario de un perfil P dete tener habilitado todas las funciones F que le correspondan.

A esto yo lo estoy analizando... y por el momento considero que se soluciona teniendo esas reglas que yo te comentaba antes. La idea es que cuando se añada o se modifique algún perfil o función, se compruebe su validez en el conjunto de reglas.

Esto lo veo como objetos, Objetos Reglas, Perfiles, Funciones... . Su dificultad es llevarlo a la base de datos... y bueno, por esto te digo que estoy en "producción". Si me entiendes un poco puede que te la ingenies para encontrar una manera de registrar las reglas (es allí el lio que yo me hago).

No se si se me entiende la idea.

Con respecto a lo que dices si es necesario tener un método, evento... o lo que sea que se encargue de chequear que tipo de perfil posee cada vez que sea necesario.... debo decirte que yo lo considero erroneo.

Mi intuición me dice que: "Cuando se inicia la seción se tiene conocimiento del perfil, y de sus permisos". Por lo que una vez validado el usuario doy por ENTENDIDO que pertenece a uno u otro perfil. No es necesario estar comprobando con cada clic (por decirlo así) si es o no una persona válida.
Ahora, distinto sería si las tareas o funciones deben ser críticas. En estos casos si considero la opción de verificar su validez. Como ejemplo: que pida algún código de activación o validación de operación.
Como medida de seguridad adicional, (y si es necesario) pondría la posibilidad de que se cierre la cesión si se detecta X tiempo de inactividad. Pero esto ya es "chucherías"

No se si habré sido de ayuda...

Disculpa el rollo.
Saludos,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita