¿Cuáles son las desventajas de usar código de filtro PHP en bloques, nodos, vistas-argumentos, etc.?

He visto muchas veces a personas que dicen que no deben usar filtros PHP / PHP personalizados (desde la interfaz de usuario de Drupal) en bloques, nodos, vistas-argumentos, reglas, etc. He buscado un poco y no he encontrado mucho, parece que Esta es una mejor práctica de Drupal que todos "solo saben".

Entiendo que representa un riesgo de seguridad potencial, especialmente en manos de usuarios finales o personas nuevas en Drupal o PHP, pero como desarrollador / creador de sitios, ¿cuáles son las razones reales para no usar PHP personalizado desde la interfaz de usuario de Drupal?

Algunos motivos:

• El código en su base de datos no puede ser controlado por versión y también es más difícil de encontrar en general más adelante.
• El código de Eval () es mucho más lento que algo codificado en un archivo.
• Si hay un error en algún lugar de ese código, recibirá un mensaje de error muy inútil (error en el código eval () 'd en la línea 3) e incluso podría haber revisado su base de datos manualmente para encontrar y corregir el error. Si está dentro de un bloque que se muestra en todas las páginas y produce un error fatal todo el tiempo, por ejemplo.
• Lo anterior también es cierto cuando se actualiza de Drupal 6 a 7 y se cambiaron las API que utilizó. Por lo tanto, tendrá que portar su código mientras migra. Si el código está en un módulo, puede portarlo por adelantado, probarlo y solo implementarlo en el nuevo sitio. Dentro de un nodo o bloque, solo funcionará con Drupal 6 o 7.
• Escribir y mantener ese código también es más difícil, porque está trabajando en un campo de texto dentro de su navegador. Tenerlo en un módulo le permite usar un editor / IDE con resaltado de sintaxis, autocompletar, etc.
• Siempre existe la posibilidad de una configuración incorrecta que le da a las personas acceso a un formato de texto / bloque / lo que sea con la ejecución de php habilitada. Si php.module (en D7, D6 no es tan estricto, por ejemplo, para las reglas de acceso de bloque) ni siquiera está habilitado, ese riesgo ya es mucho menor.
• Si su CMS permite la ejecución de PHP, un atacante que encuentre una vulnerabilidad de seguridad de XSS o escalada de privilegios ahora puede usar su servidor para cosas enormemente maliciosas (como parte de un DDOS, envío de spam, alojamiento de malware, piratería en otros sitios / bases de datos en el servidor, pirateando otros servidores en la red que podrían estar detrás de firewalls). Además de hacer que las pequeñas vulnerabilidades sean más dolorosas, esto hace que el sitio sea un objetivo de ataque más probable si se sabe que se puede usar para ejecutar php.

Puede haber más razones, pero eso debería ser suficiente :)

Este código es difícil de depurar y mantener. No conozco ninguna forma de usar el control de versiones para ese tipo de código php.

Y es realmente un riesgo potencial de seguridad para las personas nuevas en Drupal o PHP,

Considerando el caso del filtro PHP utilizado en un nodo, la razón para no usarlo es que limita los usuarios que pueden editar ese nodo, si no desea permitir que todos los usuarios usen el filtro PHP.
En lugar de usar el filtro PHP, es mejor usar un módulo personalizado que reemplace el texto específico en el contenido del nodo con el resultado del código que ejecuta (sin usar eval()), o que agregue su propio texto al contenido del cuerpo de los nodos. En este caso, cualquier usuario podría editar el nodo, sin tener el permiso para agregar código PHP arbitrario que luego es ejecutado por el filtro PHP.

En general, es mejor evitarlo eval()porque disminuye la legibilidad del código, la capacidad de predecir la ruta del código (y las posibles implicaciones de seguridad) antes del tiempo de ejecución y, por lo tanto, la capacidad de depurar el código.

Aparte de un sitio de desarrollo o prueba, no habilitaría el filtro PHP ni usaría el código PHP que se pasa eval().

El filtro PHP se ha eliminado de Drupal 8. Ahora es un módulo de terceros , no cubierto por la política de asesoramiento de seguridad . Esta es probablemente una razón más para no usarlo en servidores de producción (si las razones ya mencionadas no lo convencieron).

Como solución para los diversos problemas especificados anteriormente: dificultad de mantenimiento del código, control de versiones, búsqueda de errores, tiene esta posibilidad ligeramente "klugey":

Cree funciones (nómbrelas cuidadosamente, de acuerdo con lo que hacen) en un archivo que siempre se incluye; si tiene un módulo personalizado que está escribiendo para el sitio, es un excelente lugar para colocar estas funciones. El php que ingrese es simplemente: return my_specialfunc($somevar);- $somevaraquí podría ser el objeto del nodo en el que se trabajó, o cualquier otra variable relevante aquí.

Creo que todavía quiero la flexibilidad, en algunos lugares, de llamar a mi propio código. Al usar esta técnica, mantener el código es fácil, ya que se trata simplemente de modificar la función en el archivo. La detección de errores es fácil ya que la función se mostrará en una traza inversa.

Tenga en cuenta, sin embargo, que esto no resuelve los posibles problemas de seguridad. Estos dependen en gran medida de la seguridad del núcleo de Drupal. En general, el código contenido en la base de datos es a menudo un gran obstáculo para la seguridad: las funcionalidades que utilizan el código contenido en la base de datos tienden a ser mucho más propensas a la explotación, y la seguridad a su alrededor debe ser más estricta. Sin embargo, Drupal en general ha sido bastante bueno para mantener la seguridad de estos problemas: han surgido y luego se han parcheado / resuelto rápidamente con nuevas versiones.

Aquí está la razón de vulnerabilidad de seguridad para evitar dar este permiso a sus usuarios si no desea que sus usuarios no administradores modifiquen la base de datos directamente.

<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>

Hackear las credenciales de Drupal db

En lugar de hacer algo como return functionname($object), sería mejor usar el sistema de tokens / filtros en la medida de lo posible. Hay módulos como Insert View View e Embed Node que pueden ayudar con circunstancias comunes en las que las personas desearían incrustar PHP en los nodos o cuerpos de bloque.

Debería preocuparse por la portabilidad de sus datos. ¿Qué sucede si migra sus nodos de drupal 7 a drupal 8 y el texto del cuerpo de algunos nodos tiene <?php whatever_function_that_does_not_exist_anymore(); ?>?

No piense en su proyecto dentro de los 5 meses, sino dentro de los 5 años. Las actualizaciones, las buenas prácticas y la portabilidad son aspectos importantes de cualquier buen proyecto de TI en mi opinión.

Usar los módulos menos contribuidos posibles es también un aspecto de esto.