PHP MVC / PAC - Logged In / Admin comprueba la ubicación

8

He configurado una estructura similar a MVC / PAC para una aplicación web (no estoy seguro si se ajusta a alguno de estos patrones de diseño). En resumen es:

  • Enrutamiento en index.php , que selecciona el controlador y el método usando la URL http://example.com/controller/method/<params>
  • El método del controlador solicita datos de 'modelo (s)' y los asigna a una vista.

Ahora me pregunto cuál es el mejor lugar para un cheque registrado. Digamos que tengo una página en http://example.com/controller-one/method-one/ que requiere que el usuario sea un administrador registrado; ¿Dónde verifico si el usuario está realmente? En el enrutamiento, controlador o modelo?

Tenga en cuenta que un controlador y / o modelo puede contener métodos con diferentes 'derechos'.

Nota: hay un modelo llamado Authentication que contiene un método llamado isLogged() que devuelve verdadero o falso en función de si el usuario está conectado y otro método que se llama IsLoggedAdmin() que devuelve verdadero o falso según si el usuario es un administrador registrado.

Entonces ...: ¿Cuál es la mejor ubicación para llamar al método isLogged o isLoggedAdmin . ¿En el artículo y / o método (s) del controlador o el método y / o método (s) del modelo?

    
pregunta kgongonowdoe 03.05.2016 - 10:08

3 respuestas

2

Soy del mundo de Java, pero las cosas son bastante similares, así que aquí hay algunos consejos sobre la verificación de derechos en mi opinión.

Si su derecho es un derecho como "tiene derecho a realizar la acción X". Luego, debe verificar antes del enrutamiento y en la capa de servicio.

  • La verificación en la capa de servicio es para asegurarse de que cada vez que llame a ese servicio, tendrá dicha verificación.
  • La comprobación realmente temprana es para no tener parte de su código (recuperación de datos, ...) que puede ocurrir antes de verificar el derecho. Me dijeron que también se hizo para sostener ataques DDOS más eficientemente. Cuanto antes rechace una solicitud, mejor.

Si tiene un derecho como "tiene derecho a realizar la acción X en Y", supongo que solo puede tenerlo en la capa de servicio, como es posible en las instrucciones anteriores. Sin embargo, si su marco proporciona facilidades para realizar eso al realizar el enrutamiento, hágalo, sin embargo, francamente prefiero que el servicio se verifique, ya que la función del servicio se puede usar desde varios lugares.

Podrías tener dos juegos de Roles perfectamente:

  1. Uno como: ADMINISTRADOR / INVITADO / USUARIO: utilizado para la verificación rápida de enrutamiento, almacenado en la sesión del usuario
  2. Derechos: utilizados por la capa de servicio, almacenados en la base de datos o en cualquier almacenamiento persistente.
respondido por el Walfrat 11.05.2016 - 13:44
2

La autenticación debe ocurrir después del enrutamiento pero antes de llamar al controlador o sus métodos.

En ese momento, usted sabe qué ruta se solicitó y puede verificar si el usuario tiene privilegios para realizar una determinada acción (controladores de llamada).

Esto permite no solo separar preocupaciones, sino también decidir cómo manejar solicitudes no autorizadas antes de que lleguen a los controladores, por ejemplo. redirigirlos a otro controlador internamente con 403 respuestas.

La autenticación / autorización ocurre en una capa más alta que los modelos. Si dependen de las instancias de usuario, usted pasa la instancia ya autenticada / autorizada. Además, cuando los requisitos cambian, y otras funciones pueden llamar a métodos previamente prohibidos, solo se cambian las ACL y no los modelos.

El framework Symfony tenía una buena descripción de cómo lo hacían, todavía está disponible para v.2: enlace

    
respondido por el potfur 09.05.2016 - 17:58
0

Un intento de simplificar y aclarar.

Paso 1 : determina si existe la ruta. Si la ruta no existe, recuerde enviar un código de respuesta HTTP 404 (Not Found) además de cualquier otra cosa que haga.

Paso 2 : si la ruta existe, determine si requiere autenticación (establecimiento de identidad).

Paso 3 : si se requiere autenticación, verifique el estado de autenticación (¿el usuario ha iniciado sesión?), antes de crear una instancia de Controller .

Paso 4a : si el usuario / visitante no ha iniciado sesión, redirija a LoginController con un código de respuesta HTTP 303 (See Other) . Si falla el inicio de sesión, recuerde enviar un código de respuesta HTTP 401 (Unauthorized) .

Paso 4b : si el usuario ya se ha autenticado (ha iniciado sesión), verifique si tiene los derechos necesarios para acceder al recurso y la acción / método en cuestión (antes de instanciar un Controller ). Si él / ella / tiene derechos insuficientes, recuerde enviar un código de respuesta HTTP 402 (Forbidden) .

Es cierto que usted determina dónde termina alguien después de iniciar sesión, un error o la falta de acceso al contenido protegido. Esa no es la parte importante aquí.

Paso 5 : ahora, después de que se haya creado una instancia de Controller , asegúrese de que el usuario todavía está registrado y verifique la autorización (derechos) para realizar una acción específica .

Resumen

En efecto, la verificación de autorización y autenticación first es sobre la naturaleza de la solicitud HTTP en sí. ¿Debería permitirse que la solicitud haga que el sistema realice un gran trabajo para llegar a la acción / método que se solicita?

La segunda verificación de autenticación y autenticación consiste en asegurarse de que el estado de la solicitud sigue siendo válido en un dominio de tiempo (aunque la ventana de tiempo puede ser muy pequeña, de hecho). Las cuentas se suspenden, se degradan y se cierra la sesión todo el tiempo El hecho de que la solicitud inicial sea buena no significa que siga siendo válido .005 segundos después.

    
respondido por el Anthony Rutledge 29.08.2018 - 03:00

Lea otras preguntas en las etiquetas