Estoy trabajando para convertir una aplicación que usa el patrón tradicional de controlador de página para comenzar a usar el patrón del controlador frontal.
Uno de los problemas potenciales en los que estoy pensando es que con un controlador frontal podría ser posible que un atacante llame directamente a funciones arbitrarias.
Por ejemplo, solicitar una URL como http://example.org/articles/read/123 llamaría Articles::read( 123 ) , lo cual se espera, pero un atacante podría solicitar http://articles/some_random_helper_method/123 , lo que llamaría Articles::some_random_helper_method( 123 ) . Ese método podría afectar el estado del sistema, o dar salida a información confidencial, etc.
Obviamente, cosas como Articles::delete( 123 ) estarían detrás de un mecanismo de autenticación, pero podría haber funciones de ayuda que se utilizan para generar los resultados de las páginas públicas, pero aún así no se debe permitir que se llamen de manera arbitraria.
Esto parece ser un problema común, pero no he podido encontrar ninguna discusión al respecto.
Una solución sería implementar una convención de nomenclatura (como _private_method() para distinguir entre los métodos públicos y privados, y luego evitar que se llame a los métodos que coincidan con esa convención. Ese es el enfoque que utiliza Code Ignitor.
Eso no funcionará para mí, sin embargo, porque estoy convirtiendo una aplicación existente, y el cambio de nombre de todos los métodos rompería la compatibilidad hacia atrás. También es propenso a errores humanos, ya que se basa en que el desarrollador recuerde prefijar el método si no es público.
Otra solución sería confiar en establecer la visibilidad de los métodos a públicos o privados / protegidos, pero eso también podría romper la compatibilidad hacia atrás en mi contexto.
Otra solución sería codificar en una lista blanca de métodos públicos, pero eso no parece muy elegante.
Me pregunto si existe una solución canónica para este problema.