¿Cómo evaluar extensiones de terceros?

Si bien Magento hace mucho 'fuera de la caja', descubrimos que inevitablemente hay características e instalaciones necesarias para las tiendas de los clientes que requieren una extensión de terceros.

Sin embargo, dada la naturaleza del medio, puede ser una propuesta arriesgada introducir un código 'extranjero' en un sistema tan complejo que se ocupa de transacciones comerciales.

¿Qué buscas al evaluar las extensiones de Magento? ¿Cuáles son las 'banderas rojas' con las que te has topado (cerdos de rendimiento, riesgos de seguridad, malas prácticas arquitectónicas)?

Aquí hay algunas ideas sobre la evaluación de módulos de terceros:

Lo esencial:

• Compatibilidad con la versión actual de Magento: ¿es compatible con la última versión de Magento (incluida la actual para la que la estamos desarrollando)?

  Si un módulo no es compatible con la última versión de Magento, probablemente será difícil hacerlo funcionar sin pasar un tiempo precioso de desarrollo en él.

• Soporte: ¿los desarrolladores que crearon el módulo admiten el producto?

  Una de las señales de un módulo saludable es que los desarrolladores lo apoyan activamente. Si no lo admiten, es una bandera roja, ¿por qué no respaldarán el producto si es bueno?

  Además, cuando se admite un módulo, generalmente podemos obtener información importante de los desarrolladores con un simple correo electrónico (por ejemplo, este módulo usa jQuery o Prototype).

• Comentarios - ¿Qué dicen otros usuarios? ¿Cómo fue su experiencia?

  Al leer las reseñas podemos tener una mejor idea del panorama general, ¿hay algún problema de instalación? ¿Los desarrolladores responden de manera oportuna y útil? ¿Funciona como se anuncia?

• Reembolso: ¿Te devolverán tu dinero si no funciona como se esperaba?

  Muchas veces queremos probar el módulo para poder probarlo, si funciona y cumple con nuestras especificaciones. Pero si no es así, queremos la opción de devolverlo y obtener un reembolso por ello.

Intermedio:

• Anulaciones de clase: ¿el módulo anula las clases principales?

  En términos generales, un buen módulo no debe anular ninguna clase principal, sino que debe usar Observadores.

  Una razón para esto es que puede dificultar la actualización de Magento. Además, otros módulos pueden depender de una salida de una función determinada, y este módulo proporciona una diferente.

  A veces esto no es posible, si este es el caso, debería haber una muy buena razón por la cual está anulando una clase principal.

• Actualizaciones de diseño: ¿cambia el módulo algunas de mis configuraciones de diseño?

  Algunos módulos cambian la configuración de diseño de su sitio (por ejemplo: página del producto), se aseguran de que no rompa su diseño actual y, si lo hace, lo que se requeriría (lea: cuánto tiempo nos llevará) arreglarlo .

• Cambios de plantilla: ¿el módulo incluye plantillas que cambian mi diseño actual?

  ¿Este módulo presentará nuevas plantillas? Si es así, ¿romperán mi diseño? ¿Cuánto tiempo tomará tener el diseño de la manera que queremos?

• Dependencias: ¿depende el módulo de algún otro módulo?

  Si el módulo depende de otros, debemos asegurarnos de que estén allí e instalados. Además, debemos preguntarnos, ¿vamos a querer apagar el módulo del que depende en el futuro?

Avanzado:

• Scripts de actualización de SQL: ¿el módulo actualiza la base de datos de alguna manera?

  Una vez que un módulo actualiza la base de datos, debemos asegurarnos de algunas cosas.

  ¿Actualiza una tabla principal? En caso afirmativo, eso no es bueno, nos gusta que nuestras bases de datos estén limpias y listas para la actualización.

  ¿Almacena la información de manera sensata? Si queremos obtener los datos sin procesar de la base de datos, ¿podríamos darle sentido?

• Eventos: ¿el módulo observa o envía eventos?

  Si un módulo despacha u observa eventos, queremos saber:

  ¿Qué eventos está observando / despachando? ¿Esto afectará a otro módulo que funcione en el sistema? Por ejemplo, si uno de nuestros módulos cambia el nombre de nuestros productos en carga a mayúsculas, y este módulo agrega la palabra 'gratis' al nombre del producto en carga, ¿cómo funcionará? ¿La palabra 'gratis' también saldrá en mayúsculas?

• Revisión de código: ¿utiliza el módulo técnicas de codificación aceptables?

  Esto tiene más que ver con las técnicas de codificación PHP que con Magento.

  ¿El código usa bloques Try / Catch?

  ¿El código escapa a la entrada del usuario?

  Los detalles de esto realmente dependen de nuestro nivel de habilidad / requisitos.

• Problemas potenciales: ¿qué problemas potenciales pueden surgir como resultado de la instalación de este módulo?

  Intente imaginar los cinco problemas principales que podrían surgir si instalamos este módulo, por sorprendente que sea, realmente da una idea del proyecto en su conjunto.

Línea de fondo:

Todas estas cosas son agradables de tener en un mundo ideal, en escenarios del mundo real necesitamos hacer esto llamado 'compromiso' :)

Además, estas pautas están destinadas a ayudarnos, no a obstaculizarnos, como resultado si solo estamos instalando un módulo, digamos un módulo de intercambio social, y es para un cliente que necesita una configuración de sitio simple, allí No tiene sentido hacer un montón de investigación.

En otras palabras: se trata de ser eficientes con nuestro tiempo, si usar este (elemento en la guía) me ayuda a ahorrar tiempo a largo plazo, úselo, si no lo deja caer y ahorre cordura.

Algunas banderas rojas específicas de "malas prácticas" de Magento son:

• cualquier código en app/code/local/Mage
• plantillas sobrescritas (los archivos app/designya existen en el núcleo)
• reescribe clases esenciales como catalog/product. En general, miro cuidadosamente cada reescritura, para ver si podría haberse evitado
• violaciones graves de los estándares de codificación Zend / Magento. Si bien esto solo se trata del formato de código, concluyo que los desarrolladores que no se preocupan por los estándares probablemente también se preocuparán por otras cosas más importantes.
• cambios en las tablas de la base de datos central
• texto codificado en plantillas (sin utilizar el mecanismo de traducción) y en otros lugares
• lógica empresarial en plantillas (regla general: cualquier aparición Mage::getModelen el directorio de plantillas suele ser una mala señal)

Algunas banderas rojas relacionadas con PHP (esta es una lista muy selectiva e incompleta):

• Avisos y advertencias con informes de errores habilitados ( E_STRICT)
• uso del @operador
• no desinfectar los datos del usuario antes de la salida

Algunas banderas rojas relacionadas con el rendimiento:

• consultas de bases de datos dentro de bucles
• cargar una colección completa solo para usar una parte de ella

También tenga cuidado con los olores de código generales , que no son señales de alerta necesarias pero ayudan a estimar la calidad general.

Paso # 1: ¿Puede su cliente permitirse el lujo de admitir esta extensión si el desarrollador deja de trabajar?

Si no, no puede usar la extensión.

En caso afirmativo, proceda a la evaluación de la extensión.

La buena gente de Inchoo tiene un artículo sobre el análisis del código del módulo de terceros. El artículo menciona reescrituras de clase, trabajos cron, actualizaciones de diseño y observadores de eventos.

He encontrado que el código de observador de eventos tiene el potencial para el mayor rendimiento. Esté atento a los códigos de terceros de uso intensivo de recursos que se ejecutan para eventos enviados con frecuencia. Eventos como, controller_action_predispatch o cargas de recopilación.

Utilizo este módulo de utilidad de Prattski para obtener una buena visión general de reescrituras y observadores.

Tener plantillas y activos de máscara ubicados en default / default (o pro o enterprise) en lugar de base / default es bastante molesto.

El código ofuscado es algo a tener en cuenta: busque llamadas a eval (), base64_decode () y similares. Esto se usa a menudo para la validación de la licencia, pero puede ser malicioso o aterrador: he visto al menos un componente que evaluó el código arbitrario de una fuente RSS.

Busque llamadas dl (): ¡al menos un componente de pasarela de pago que he visto requiere la instalación de una extensión PHP para hacer sus conexiones!

Tienes razón.

Desafortunadamente no hay magia: tienes que probarlos, verificar el código para ver si está bien desarrollado, tener un buen soporte para módulos comerciales gracias a su foro o rapidez para responder a tus preguntas ...

Hay algunas revisiones en Magento Connect y la popularidad de una extensión puede ayudar a saber si es valioso o no, pero honestamente puede encontrar módulos muy populares con muchos errores. Tuve un buen ejemplo la semana pasada con un módulo MailChimp, principalmente bien hecho, pero tuve que corregir algunos errores y se los proporcioné al desarrollador. Siempre hay riesgos, tienes que probar.

WebShopApp tuvo la idea de avanzar en esta dirección, quiero decir, traer una plataforma para obtener buena información sobre los módulos. La idea era empujar a Magento en esta dirección. Entonces la calidad del módulo es una pregunta real.

Mi consejo: preste mucha atención a los módulos que tienen scripts de instalación / actualización que cambian los valores en las tablas principales porque no siempre es fácil deshacer ese tipo de cambios.

La prueba n. ° 1 que se me ocurre es encontrar un exploit de día cero en su código (generalmente no es muy difícil con las extensiones de Magento), informar solo a su equipo de seguridad sobre el daño resultante de un exploit simulado (sin dar ninguna indicación de qué parte del código es vulnerable) e inicie el cronómetro, porque esto es exactamente lo que sucederá cuando su sitio sea pirateado. Cuando su personal de soporte solicite acceso global a FTP y mysql, rechace cortésmente declarar que está violando el PCI-DSS y ofrezca permitirles tener acceso de solo lectura a su repositorio de código fuente.

La prueba número 2 que realizo es llamar al vendedor y pillarlo desprevenido. Pregúnteles qué tipo de pruebas de comportamiento / unidad hacen, qué sistema de control de fuente usan, qué versiones de PHP prueban, qué versiones de Magento se prueban, qué servidores web se prueban, si usan o no el navegador -pila para probar los componentes frontales, etc. Si el proveedor no sabe de qué está hablando, se queda en silencio o quiere "pedirle a un experto que le envíe un correo electrónico", corra como el infierno porque lo más probable es que estén numerados archivos zip para "control de versiones" y solo corrige errores 3 meses después de que sus clientes los reportan.

Hablando de PCI-DSS, todas las modificaciones del sistema también deben tener una estrategia de reversión. Con módulos que agregan columnas no anulables a las tablas principales, esto se vuelve casi imposible mientras se mantiene una estrategia de reversión que pasaría una auditoría. Ejecútese como un demonio desde cualquier módulo que cause problemas (lea: Errores de SQL) cuando esté deshabilitado.

PCI-DSS v3

6.4.5.4 Procedimientos de retroceso.

Verifique que los procedimientos de retroceso estén preparados para cada cambio muestreado.

Para cada cambio, debe haber procedimientos de retroceso documentados en caso de que el cambio falle o afecte negativamente a la seguridad de una aplicación o sistema, para permitir que el sistema vuelva a su estado anterior.

Esto, además de las otras respuestas. En mi opinión, debería haber un muro de vergüenza por parte de la basura peligrosa que se ha generado en esta plataforma.