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

96

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?

Laxman13
fuente
1
Como de costumbre, ¡depende de la situación! Si solo necesita un bloque $ print básico en la parte inferior de su página de Vistas en un 'pie de página de vistas', podría ser ideal hacerlo solo a través de la interfaz gráfica de usuario en lugar de escribir un archivo tpl completo para ese propósito. Por supuesto, esto también depende del papel del sitio y otros factores: ¿Plazo ajustado? Sitio de la comunidad de usuarios? ¿O solo un sitio informativo? ¿Es vital para las operaciones comerciales? etc ... depende.
Patoshi パ ト シ

Respuestas:

129

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 :)

Berdir
fuente
3
Buena lista :) con suerte será un recurso para otros
Laxman13
3
@ Laxman13: "para los demás" ... ¡y para ti también! : D @Berdir: +1, muy buenos aspectos. Por cierto, no tiene que escribir todo el código en un campo de texto, ya que también puede incluir un archivo allí. Por ejemplo, puede poner solo una línea en el campo de texto: require_once $_SERVER['DOCUMENT_ROOT'].'/sites/all/themes/myTheme/php/stuff.php';y escribir el resto del código en su IDE / editor de texto. A veces no es un trabajo fácil o llevaría mucho tiempo crear un módulo propio, incluso como un buen desarrollador de PHP. Un breve ejemplo: acciones condicionales de Ubercart. Pero es cierto que no es bueno mantener nuestro código en db.
Sk8erPeter
Quiero decir, por ejemplo, el módulo UC Conditional Actions tiene una GUI muy buena que ahorra mucho tiempo al tener que escribir nuestros propios códigos largos. Puede crear una acción realmente compleja en minutos con un método "next-next-finish" en una GUI. Pero tal vez desee ampliar la funcionalidad con algunos de sus propios códigos; en muchos casos, simplemente no vale la pena desarrollar un módulo para ese propósito.
Sk8erPeter
1
+1000: lo he visto, tantos proyectos quemados por casi todos los puntos en esta lista. Solo hubo una vez en toda mi vida que usar el módulo PHP era la única forma de hacer algo de una manera sensata, y eso fue solo debido a un problema con D6 que se solucionó en D7.
geerlingguy
Gracias por sus detalles responda a esta pregunta. Encontré una situación mientras trabajaba en Drupal, que cuando necesitamos agregar un enlace en 'editor de texto', necesitamos usar el código php en 'filtro de texto', de lo contrario no funcionará como se esperaba.
Jayendra Kainthola
17

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,

ya.teck
fuente
1
Bueno, si la configuración de bloque exportada al código con módulos de características no es un problema poner fragmentos de php bajo control de versión.
ya.teck
14

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).

kiamlaluno
fuente
11

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.

James
fuente
11

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

lolcode
fuente
7

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.

Evan Donovan
fuente
0

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.

Stef Van Looveren
fuente