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