¿Debe la autorización ser parte del modelo o controlador?

Question

Estoy escribiendo una aplicación web con algunos requisitos ACL: un usuario puede hacer cambios en algunos elementos, algunos pueden editarlos varios usuarios, el administrador puede editar cualquier cosa y un administrador puede editar todo dentro de su organización, etc.

¡Estoy usando Play! marco, y por el aspecto del módulo Secure, parece que el lugar para poner preocupaciones de autorización está en los Controladores. Sin embargo, me parece que los problemas de autorización son parte de la lógica comercial y, por lo tanto, deberían estar en el modelo. Además, estoy empezando a ver una lógica duplicada en los controladores que necesito refactorizar.

Por otro lado, agregar autorización al modelo significa que tendría que haber alguna manera de obtener el usuario actual dentro del modelo, lo que no parece correcto. Alternativamente, podría agregar un parámetro "current_user" a cada método de modelo, pero eso parece incluso peor.

¿Cuál es la práctica más común? ¿Puedo/debo poner código de autorización en el modelo o mantenerlo en el controlador?

Answer 1

Creo que esta es un área gris. Se podría argumentar que el acceso de los usuarios es parte del mapeo entre el mundo HTTP y el mundo orientado a objetos. Para eso está diseñado el controlador (de ahí el uso intensivo de estática), para transformar la solicitud entrante, listo para procesar las reglas comerciales en el modelo de dominio.

Sugeriría que la lógica del controlador es absolutamente el lugar correcto para controlar el acceso al modelo, especialmente porque esto se gestiona principalmente en un nivel de anotación, y la autenticación se abstrae a una clase de seguridad.

Answer 2

En la mayoría de los casos, la seguridad debe ser de una (o más) capa por encima del modelo. La seguridad es un dominio en sí mismo, lo que restringe el acceso a una capa de nivel inferior.

No creo que la seguridad deba hacerse a nivel del controlador.

En mi opinión, esto debería verse así:

Ver -> Controlador -> Seguridad -> Modelo

La capa de seguridad podría ser una fachada o un proxy con respecto al modelo, la protección del acceso, pero ser transparente para el controlador.

Sin embargo, si las vistas se van a modificar dependiendo de los derechos de acceso del usuario, algunas verificaciones podrían tener lugar en el nivel de controlador (como establecer el valor de una propiedad booleana CanEdit en el modelo de vista).

Answer 3

¡A mí personalmente me gusta mucho la forma en que se juega! El módulo seguro maneja esto (the tutorial is ever-helpful here). Si no te importa usar la anotación @Before, es bastante sencillo.

Answer 4

La autorización no debe formar parte del controlador ni del modelo de dominio.

En su lugar, debe estar en la capa de servicio.

El controlador solo debe actuar como despachador y delegar entre HTTP y el servicio de la aplicación. Es el servicio de aplicación donde se lleva a cabo la orquestación. Este es el mejor lugar para colocar la autorización.

Supongamos que el usuario A está autorizado para acceder a los datos del dominio X, pero no está autorizado ni siquiera para acceder a los datos del dominio Y.Si la autorización se coloca en el controlador, entonces el usuario A obtiene autorización en el controlador X, y a través de las llamadas de servicio puede acceder a los datos del dominio Y, que no es lo que esperábamos.

Dado que los modelos de dominio se comunican entre sí en la capa de servicio, por lo tanto, es mejor colocar la autorización en el mismo nivel.

Answer 5

estoy en esta etapa y con la intención de manejar esto de la siguiente manera:

• Ninguna forma de validación de JS, en lugar a través de HTTPS ajax

• Una clase PHP Ajax

• Los datos de formulario enviados a un modelo como sus datos para la validación concreta para el tipo común
  , como el correo electrónico y la contraseña (probablemente la validación de la matriz assoc será reutilizada por otras clases, por lo que esto es definitivo ely un área modelo).

• si no hay error una búsqueda en una tabla de usuario para las credenciales de correo/
  credenciales de la contraseña se pasan a un controlador con la autenticación
  tipo tales como entrada/registro/restablecimiento de contraseñas

• el controlador produce entonces la vista de salida requerida o establece usuario que ha iniciado la sesión, etc.

esto se basa en laravel pero tengo mi propia biblioteca como quiera que independiente de laravel y justo basado libremente para este vita l requisito.

El punto es que el Modelo busca las credenciales requeridas como datos, luego las envía al Controlador ya que no le importa cómo debe procesarse. Creo que esta es la única forma de hacer de esta área una responsabilidad definitiva entre cada uno de los componentes.

Answer 6

Desde mi experiencia personal con marcos MVC, diría:

1. Modelo es un objeto que representa a la mesa de base de datos debe ser puro y no debe contener ninguna lógica adicional.

2. El controlador es el lugar donde se toman las decisiones y otra lógica personalizada , por lo que la autorización debe estar en el controlador. Es se podría diseñar algún gancho que pueda verificar si el usuario está autorizado o no en todos los lugares necesarios por lo que no tendrá un código de repetición SECO.

3. La mejor manera de dar permiso al usuario si está utilizando una arquitectura típica resto es para hacer un símbolo, guardarlo en la DATABSE y en lado del cliente y verificar este token en cada petición. Si está utilizando la aplicación del navegador web , puede usar las sesiones del lado del servidor para la autorización ( Es mucho más fácil).

Así que mi propuesta es mantener la lógica de autorización en el controlador.