PHP OOP - ¿Cómo se maneja la autorización?

Question

Estoy construyendo un sistema de gestión para una idea que tengo. Estoy muy versado en PHP (al menos lo suficiente para hacer todo lo que necesito hacer) pero no tengo tanta experiencia con el uso de OOP. Lo uso tanto como puedo pero muchas de las mejores prácticas con las que no estoy familiarizado, así que cuando hago las cosas me preocupa que las esté haciendo en el orden equivocado.

Para este proyecto tengo una clase para lo que el usuario está administrando, necesito verificar si el usuario tiene o no permisos para administrarla. Sé cómo para verificar los permisos, mi pregunta es: ¿dónde debería estar?

debería hacer que fuera de la clase, así:

if user permissions are valid 
initialize class 
else return error 

o debería estar haciendo

initialize class 
class checks permissions 
class returns error if permissions are invalid 

estoy seguro de cuál es el enfoque correcto . Por un lado, revisar dentro de la clase parece ser el mejor basado en lo que sé de la metodología de OOP, pero también tengo la sensación de que dejar que se llegue a la inicialización de la clase cuando se desconocen los permisos podría ser malo.

¿Cómo debería hacerlo? Si hay algún tipo de artículo que cubra este tipo de cosas, un enlace sería muy apreciado (no puedo encontrar nada a través de las búsquedas, pero no estoy 100% seguro si estoy buscando lo correcto, ya que sé muy poco de OOP)

Answer 1

Depende de cuál es su modelo de permisos, y no hay "una forma correcta" de hacerlo. Es una cuestión de enfoque. Lo importante, es que sea lo que sea que elijas, lo usas constantemente.

En mis últimos proyectos, encontré varios modelos diferentes. Una de las más sencillas es un permiso basado en página, que es bueno si se realiza un flujo basado en páginas, y se usan objetos para soporte: se define en la parte superior de la página quién debe acceder y en caso de que se pueda redirigir. Este es el más simple, pero puede ser muy útil en aplicaciones específicas.

Si, por el contrario, usa objetos para hacer su flujo principal, debe asegurar sus métodos de objeto (en lugar de creación de instancias de clase). Si tiene un método "guardar()", que solo puede ser llamado por usuarios específicos, lo primero que debe hacer al ingresar a ese método es verificar sus permisos.

Actualmente estoy usando un patrón MVC, y tengo un controlador, que distribuye las acciones a sus hijos. Su único método público es execAction($params) y llamará al actionAction($params) en sí mismo, pero primero comprobará los permisos.

Una cosa importante para recordar es: nunca presentes acciones en la interfaz de usuario que el usuario no tiene permiso para hacerlo (a menos que usted está tratando de obligarlo a comprar su versión "PRO", se entiende) ;-)

Answer 2

Creo que la mejor manera de hacerlo es tener clase de permisos. Y luego puede verificar antes de crear el objeto o en el objeto.

create permission class 
if access then create class and set permission object 
else error 
// do action 
if have permissions show something 
else do not show something 

Mira que hace en zend acl component

Answer 3

He escrito un sistema CMS bastante sólido y robusto. Así es como lo hago y espero que pueda extrapolar algo de información sobre cómo hacer su propia solución.

• Tengo un archivo de índice, que carga una clase Admin. La funcionalidad en mi CMS es modular (por lo que contiene en su propio archivo y clase).
• Un módulo se carga según un parámetro $_GET.
• Debido a que la función para comprobar el parámetro $_GET y cargar la función correspondiente está en mi clase Admin ($admin->pick_method()) y también tengo un objeto User en mi clase Admin, puedo comprobar primero el módulo solicitado está en el usuario actualmente conectado de matriz de permisos.
• Si la verificación de permisos devuelve true, cargo el módulo. Si false, aparece una página amigable de "acceso no autorizado".

Espero que esto ayude.

Answer 4

La validación dentro de la clase genera una dependencia entre la clase y la autorización de permisos que no es buena porque está uniendo dos posibles elementos dispares. Puede resolver esto por Inversion of Control (por ejemplo, dependency injection) o como lo hago por authorisation notifications using Emesary.

La validación fuera de la clase es posiblemente peor porque existe un peligro real de que la verificación de la autorización sea incorrecta o se omita por completo. También crea un tipo incorrecto de enlace entre objetos ya que el objeto no tiene el control de sí mismo.

Si va a hacerlo fuera del objeto cuando se crea, entonces es mejor pedirle al objeto que proporcione un interface como IAuthorisable que puede ser verificado por un objeto separado.

p. Ej.

interface IAuthorisable 
{ 
    public function getRequirements(); 
} 

class Authorisation 
{ 
    public static createObject($newObj) 
    { 
      if (canDo($newObj->getRequirements())) 
       return $newObj; 
      return null; 
    } 
} 

class Something implements IAuthorisable 
{ 
    public function getRequirements() 
    { 
      return SomeSortOfIdentifierOrSomething; 
    } 
} 

$mySomething = Authorisation::createObject(new Something($p1, $p2), " 

Si $ mySomething is null no está permitido. Obviamente, esto necesita extenderse y diseñarse correctamente, lo cual queda como un ejercicio para el lector.

Answer 5

fundamentos OO
Si tiene sentido incluirlo en la clase. Usted podría hacerlo.
¿Una clase de libro tiene una función de autenticación? No, funciones como download() y convertToPDF() tienen más sentido.

Mi enfoque
Siempre trato de encontrar la vía de la menor resistencia.

Si hay 10 scripts/páginas que hablan con 1 clase y 1 o 2 scripts necesitan autenticación para ciertas acciones, construiría la autenticación en esos 1 o 2 scripts. (o póngalos en una subcarpeta con un .htpasswd)

Pero cuando está usando una estructura MVC, todo es una clase, por lo que se convierte en una cuestión de decidir qué clase.
Tiendo a poner las reglas de autenticación en las clases de Controladores y la autenticación a la lógica de la base de datos en una clase de Usuario.