De usuarios y roles

[dec]

Hola pataliebres,

Una vez más necesito de vuestros sabios consejos. En esta ocasión os quiero preguntar acerca de "usuarios y roles de usuario", que, es algo que me trae últimamente de cabeza, y, sobre lo que no tengo ninguna experiencia, y, con lo que no quisiera meter la pata.

A ver si soy capaz de explicarme. Si no lo consigo, y queréis, no dejéis de decirlo para y lo intentaré de nuevo o aclararé lo que haga falta. ¿De acuerdo? Pues, vamos allá.

Estoy trabajando en una aplicación que permite distintos tipos de usuario. Están los usuarios de la aplicación, propiamente, dicha, y, los usuarios que pueden administrar los datos con los que juega la aplicación, por decirlo así.

Estos últimos usuarios pueden ser de tres tipos, por ahora: administradores, editores y autores. Cada uno de estos tipos pueden hacer diferentes cosas, o, si se prefiere, cada uno de ellos no puede hacer según qué cosas.

Los administradores pueden crear usuarios y hacer todo lo que pueden hacer el resto de usuarios. Los editores pueden añadir datos en la aplicación, y editar sus datos y los de otros usuarios. Los autores, sencillamente, pueden añadir datos y editarlos, pero, sólo si los añadió él.

Bien. Lo que a mí me preocupa es lo siguiente. Hasta ahora, es en la interfaz de la aplicación donde se determina qué puede hacer un usuario y qué no. Si habláramos de Delphi, diríamos que la aplicación muestra este o aquél formulario a según qué usuarios.

De modo que si un usuario no tiene permisos para añadir otros usuarios, y trata de abrir el formulario para añadir nuevos usuarios... la aplicación, por decirlo así, no le muestra el formulario, y así, en un principio, podría pensarse que el usuario no consigue lo que quería.

Pero (no quisiera liarme mucho... os pido disculpas por el rollo), pero, digo, me queda la duda de si tengo que ir más allá y, además de no mostrar a un determinado usuario el formulario para añadir otros usuarios, si no tiene los permisos suficientes, me queda la duda de si además no debería mirar estos permisos cuando voy a añadir usuarios en la base de datos.

Esto es. El usuario no puede aquellos formularios que permiten tareas sobre las que no tiene privilegios, porque, la interfaz de la aplicación se lo impide, por decirlo así. Pero, cuando un usuario tiene los permisos suficientes, la interfaz le muestra el formulario oportuno, este hace "clic" en el botón correspondiente, y...

Hay un método de una clase que hace lo que sea menester: inserta un nuevo usuario, edita los datos de uno ya existente, etc. Ahora bien, la pregunta concreta podría ser, ¿debo también en este método averiguar si el usuario que lo está ejecutando tiene los permisos adecuados? ¿Basta con limitar al usuario la interfaz "que no puede ver"?

La verdad es que sobre estos temas estoy bastante pez. Yo supongo que me va a tocar añadir "la comprobación" en los "métodos" que llevan a cabo determinadas tareas, pero, no tanto por temor a los usuario, cuando a otras partes de la aplicación, y me explico, brevemente.

La aplicación que estoy desarrollando puede permitir "plugins" en un futuro. Ahora no cuenta con esta posibilidad, pero, es probable que sea así en un futuro. Ahora bien, algo como los "plugins" no trabajan "desde la interfaz" de la aplicación... y, por lo tanto, podrían ejecutar un determinado método, que insertara los datos de un nuevo usuario, por ejemplo, y, si no compruebo si se tienen permisos suficientes... lo insertaría sin problemas...

Ahora bien. ¿Podéis decirme algo sobre todo esto? ¿Tenéis alguna experiencia con aplicaciones de este tipo, que permitan diferentes usuarios, con diferentes permisos? A ver si me podéis echar una mano en base a vuestra experiencia o, en todo caso, con lo que queráis decirme al respecto.

Bueno. Muchas gracias a todos de antebrazo, digo antemano. Y disculpad el rollo, por favor.

PD. A mí se me hace raro que la "clase BD", por ejemplo, tenga que estar mirando a cada momento (en cada método, o buena parte de ellos), si el usuario que los ejecuta está autorizado o no... Pero seguro que me estoy perdiendo algo... estoy seguro...

[[Caral]]

Hola Dec
Se que poco podre ayudarte por que para empezar no se lo que son los "plugins", pero en el programa de la fabrica tengo varios tipos de permisos a los diferentes usuarios.
Esto lo hice (con vuestra ayuda) agregando un campo a la tabla usuarios (B1) de tipo numérico en la que según el numero del 1 al 5 tienen acceso a una parte del programa determinada, esto lo hago directamente cuando se loguean en el.
Si quieres te paso el programa completo con base de datos y todo así lo revisas, tal vez te sirva de algo, por lo menos te reirás un rato.
Saludos

[dec]

Hola,

Gracias Caral. Bueno. Yo hago algo parecido en la aplicación que comento. En una tabla de la base de datos se guarda lo necesario para "asignar a cada usuario" un "nivel". Cuando un usuario se autentica en la aplicación se recoge el dato y desde ese momento el usuario tiene ya un nivel asignado, un rol, y, por tanto, unas "capacidades".

Pero, hasta el momento, únicamente estoy evitando que un usuario puede hacer esta o aquella cosa, desde la propia interfaz. Básicamente, lo que he comentado antes: un usuario trata de acceder al formulario de inserción de registros; se comprueban sus permisos; no tiene suficientes; se le redirige a otro lugar, no se le enseña el formulario en cuestión.

Pero, si el usuario tiene permisos... la intefaz "le deja pasar", y, cuando el usuario inserte un nuevo registro, pongamos por caso, se ejecuta un determinado método de una clase "BD". Es en esta clase donde ahora mismo no distingo entre usuarios... es decir, es como si dijera, "oyes, si has podido ejecutar este método, entonces asumo que tienes los permisos para ejecutarlo".

Y no sé si eso basta o si tendría que también ahí, en el propio método que inserta nuevos registros a la base de datos, si tendría, digo, que volver a comprobar si el usuario en cuestión tiene o no permisos suficientes. Lo de menos es hacerlo. O sea, que no es por no hacerlo, es que no estoy seguro de que se deban de enfocar así las cosas o qué.

Un "plugin" viene a ser una especie de añadido a la aplicación. Digamos que la aplicación no puede imprimir registros. Pero, permite "instalar plugins", de modo que algún plugin pueda imprimir, efectivamente, registros. Ahora bien, aquí está parte del asunto que me preocupa: el plugin no "pasa" por la interfaz.

El plugin se ejecuta "junto con la aplicación", no es un usuario, y, por tanto, no necesita pasar por un formulario en la interfaz para acceder a los registros, por ejemplo. Ahora bien, entonces, me pregunto ahora, ¿es el autor del supuesto plugin quien tiene que preocuparse de que un usuario tenga permisos suficientes para hacer esta o aquella cosa?

¿En todo caso, independientemente de lo que haga el plugin, en todo caso, digo, sería mejor que el método de la clase "BD" que añade registros a la base de datos, comprobara si el usuario que ejecuta el método tiene permisos o no los tiene? Pensando en ello comienzo a pensar de esta manera... creo que va a ser necesario que el propio método compruebe si el usuario dispone de permisos... además de la interfaz...

Y ya digo, que no es por no hacerlo así, sino que me quedan dudas...

[[Caral]]

Hola
Bueno como hace rato de no doy una, pues una mas no cuenta.
A lo que entiendo un plugin es un programa aparte que permite conectarse con el programa (principal) y hacer ciertas cosas.
Bueno, normalmente lo que hacemos es conectarnos a la bd directamente desde el programa, es lo mas facil.
Hacer una comprobacion de cada paso por usuario me parece que seria lento y ademas mucho codigo.
Que tal hacer un programa aparte que sea este el que se conecte a la bd y que tanto el programa principal como el plugin tengan que pasar por el?,
(este seria el que comprobaría los permisos).
Ya se, la idea descabellada, no se puede esperar mucho del novato.
Saludos

[dec]

Hola,

Sí ArdiIIa, lo cierto es que muchas ideas estoy cogiendo de WordPress, por ejemplo. Pero que muchas... sin ir más lejos esto de los "roles" de usuario, en buena medida viene de ahí, sin embargo, en esto me he apartado un poco... bastante. Y he mirado por encima el asunto de los "roles" de usuario en WordPress... y me asusta. De hecho, lo he contado hoy en mi weblog, estoy temiendo que se me caiga todo el teatro encima, porque,... se me ha hecho tan "sencillo" que no me lo creo... algo fallará tarde o temprano... casi estoy seguro... o, lo que es peor aún, no estoy seguro...

Y, Caral, lo que dices no es ninguna tontería. Algo así he pensado yo también, si bien ahora mismo no sería capaz de explicar el tema. Sin embargo, comprobar si un usuario puede insertar registros, por ejemplo... significa una línea de código... es algo así como esto:

Código PHP:

if($user->Can(ROLES_CAP_MANAGE_POSTS)){
  // Puede hacerlo...
} 


Ahora bien... aunque es una línea de código... hasta ahora la clase "BD" se ha mantenido "al margen" de estos asuntos. Por ejemplo, en el caso de la validación de datos, que es otro tema, pero, sirve al caso. La clase "BD" no valida datos. Da por supuesto que lo que le llega es válido. La clase "BD" únicamente "valida" lo suyo, es decir, se asegura de "escapar" ciertos caracteres que no deben entrar "tal cual" en la base de datos, pero, no se preocupa de si el nombre de un registro es válido, por ejemplo, sino que da por supuesto que lo que se le pasa lo es.

Pero,... ahora, con el tema de los usuarios... Vamos a suponer una cosa. Supongamos que la aplicación no tiene plugins ni los va a tener. ¿En este caso el asunto parece más claro, no? Quiero decir, el usuario no "llama métodos" de la clase "BD". Es la interfaz de la aplicación la que, por decirlo así, llama los métodos oportunos de la clase "BD".

En este caso, si un usuario no puede añadir registros, por ejemplo, no tendrá jamás acceso al formulario que los añade, y, por tanto, no podrá añadirlos, sin más. ¿Verdad que esto sí que parece más claro? A mí me lo parece, por lo menos... no sé si es tan claro como me parece a mí...

Pero, si "alguien" más puede llamar métodos de la clase "BD", como un plugin de la aplicación, por ejemplo, entonces ya es otra cosa... ¿Al menos los métodos "susceptibles" de ser llamados por un plugin deberían controlar si el usuario cuenta con los permisos suficientes? ¿O todos los métodos de la clase "BD" deben hacer esta comprobación?

Por otro lado, se me ocurre al hilo de lo que escribo, y siguiendo un poco lo que dices Caral, fíjate, ¿no podría contarse con un "módulo" aparte, que hiciera las veces de "interfaz" entre la clase "BD" y los plugins? De este modo, los plugins no podrían sino comunicarse con dicha interfaz, y, ahora sí, la interfaz comprobaría que el usuario de turno tiene los permisos suficientes para hacer esta o tal cosa... hum... tal vez por aquí pueden ir los tiros.

Otra cosa sería, claro está, impedir que un plugin hiciera uso de la clase "BD"... la aplicación hace uso de la clase "BD" en una determinada forma: esta clase se instancia en una variable "global", que, por tanto, estaría disponible para los plugins... así que... no sé yo si estamos en las mismas... aunque, quizá hemos avanzado algo, y, por otro lado, tal vez podría encontrarse la forma de averiguar si es un "plugin" quien ejecuta un determinado método de la clase "BD", aunque, a bote pronto, me parece complicado...

[dec]

Hola,

Todo ayuda Delphius. ¿Sabes qué pasa? Que al cabo he "conseguido" (todavía lo pongo en duda) un sistema de privilegios, de "roles", muy, pero, que, muy sencillo... vamos, a mí me lo parece, y, desde luego, comparándolo con el de WordPress (que es un sistema similar al que traigo entre manos, si bien el mío es mucho más humilde), digo, en WordPress es un asunto bastante complejo, o a mí me lo parece.

Sin embargo, voy a mostrar la "burrada" que he preparado para asignar diferentes permisos a diferentes usuarios. A continuación el método "InitializeUserRoles()" de una clase "Roles":

Código PHP:

  private function InitializeUserRoles(){
    // 10 = Admin user
    $this->userRoles[10][ROLES_CAP_MANAGE_SITE] = true;
    $this->userRoles[10][ROLES_CAP_MANAGE_LINKS] = true;    
    $this->userRoles[10][ROLES_CAP_MANAGE_TERMS] = true;  
    $this->userRoles[10][ROLES_CAP_MANAGE_POSTS] = true;   
    $this->userRoles[10][ROLES_CAP_MANAGE_USERS] = true;    
    $this->userRoles[10][ROLES_CAP_MANAGE_THEMES] = true;
    $this->userRoles[10][ROLES_CAP_MANAGE_IMPORT] = true;    
    $this->userRoles[10][ROLES_CAP_MANAGE_EXPORT] = true;    
    $this->userRoles[10][ROLES_CAP_MANAGE_OPTIONS] = true;
    $this->userRoles[10][ROLES_CAP_MANAGE_PROFILE] = true;      
    $this->userRoles[10][ROLES_CAP_MANAGE_COMMENTS] = true;
    // 9 = Editor user
    $this->userRoles[9][ROLES_CAP_MANAGE_SITE] = true;
    $this->userRoles[9][ROLES_CAP_MANAGE_LINKS] = true;    
    $this->userRoles[9][ROLES_CAP_MANAGE_TERMS] = true; 
    $this->userRoles[9][ROLES_CAP_MANAGE_POSTS] = true;     
    $this->userRoles[9][ROLES_CAP_MANAGE_PROFILE] = true;          
    $this->userRoles[9][ROLES_CAP_MANAGE_COMMENTS] = true;
    // 8 = Author user
    $this->userRoles[8][ROLES_CAP_MANAGE_SITE] = true;    
    $this->userRoles[8][ROLES_CAP_MANAGE_POSTS] = true;  
    $this->userRoles[8][ROLES_CAP_MANAGE_PROFILE] = true;    
    return true;
  } 


Eso, que estoy seguro de que puede mejorarse (pero, ahora no estamos viendo eso), se resume en "El usuario con nivel 10 puede administrar el sitio", "El usuario con nivel 10 puede administrar enlaces", etc., etc. Luego, como puede verse, según bajamos el nivel del usuario este puede hacer menos cosas. Eso sería una especie de "tabla de capacidadades según el nivel de cada usuario".

Hay que decir que la clase "Roles" sirve a una propiedad de la clase "User". La clase "User" cuenta con una propiedad (variable, miembro) del tipo "Roles". Cuando se instancia la clase "User" se asigna a la variable "userlevel" (del tipo "Roles") un determinado nivel y, la propia clase "User" cuenta con un método "Can()" que lo que hace es llamar a este otro de la clase "Roles":

Código PHP:

  public function UserCan($capability){    
    if(isset($this->userRoles[$this->userLevel][$capability])){
      return $this->userRoles[$this->userLevel][$capability];  
    }else{
      return false; 
    }
  } 


Que, como puede verse, viene a comprobar si el usuario del nivel que sea, puede realizar una determinada tarea, tiene la capacidad de realizarla. Básicamente en eso se resume todo... (!). En la base de datos hay una tabla "users" y otra tabla "usersmeta", que están relacionadas. A cada usuario le corresponde un nivel, que se guarda en "usersmeta". Y eso es todo... No hay más... ¡y parece funcionar!

Pero,... francamente, no entiendo entonces a qué tanto "lío" en WordPress con los permisos... y, como sé perfectamente que WordPress es mucho WordPress, y que mi sistema no le llega a la altura de los zapatos... no tengo sino pensar que en algo estoy metiendo la pata, que lo que he hecho no está bien hecho, porque, ¡no puede haberme resultado tan sencillo, ni, en general, resultar tan sencillo como parece y es!

Pero, para terminar, aquí aplica aquello de "Eppurse muove"... porque, con todas las dudas que hay todavía por ahí rondando, el caso es que parece que el puñetero sistema funciona...

En todo caso, y, en lo que respecta a esto último, tal vez debería hacer lo que ha recomendado ArdiIIa, esto es, mirar algún otro programa similar y estudiar su funcionamiento. Y a lo mejor para lo que planteo desde un principio tampoco estaría mal que hiciera esto, pero, bueno, qué leches, quería comentar aquí el asunto a ver qué os parecía a vosotros.

[[ArdiIIa]]

Señor:

Extensa pregunta venida de un gurú.

Si estuviéramos hablando de Delphi, te daría un planteamiento de esos de andar por casa que suelo meter yo, ahora bien, como creo que no es ese el caso y la envergadura del asunto va mucho mas allá, así en voz bajita te diría que le eches un vistazo al código de Joomla, que como creo que sabes, todas operaciones las hace estupendamente.
Ahora bien, no creo que por hacer esto que te propongo, reste creatividad ni mérito a lo que te traes entre manos y nada más dec.

Así que ahora, también bien

Un saludo.

[[Delphius]]

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í:

---- 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,