Saltar al contenido

Categoría: Wordpress

JS Archive List 6.2.0: actualización de seguridad, limpieza de i18n y más pruebas automatizadas

Hay actualizaciones “cosméticas” y otras de urgencia, con un enfoque en la calidad, porque resuelven problemas que surgen en producción. La versión 6.2.0 de JS Archive List se clasifica en la segunda categoría.

En la sección de changelog de WordPress, el foco está clarísimo: es una actualización de seguridad y viene acompañada de mejoras que, aunque no se vean en el frontend, hacen que el plugin sea más sólido a largo plazo.

JS Archive List de nuevo con una vulnerabilidad

El cambio importante: fix de seguridad en filtros por shortcode

El punto más relevante de esta versión de JS Archive List es que se corrigió una deserialización insegura relacionada con los filtros de categorías del shortcode, pasando a un enfoque de parsing seguro de IDs serializados y rechazando cualquier otro valor, como, por ejemplo, un objeto.

Es decir, si tu sitio usa shortcodes y filtros de categorías, ahora el plugin es mucho más estricto con lo que acepta como entrada. Esto reduce superficies de ataque clásicas en las que “datos con forma rara” terminan ejecutando acciones que nunca debieron ejecutarse.

No es el tipo de cambio que “se nota”, pero es exactamente el tipo de cambio que vale oro.

i18n sin sorpresas: text domain alineado con el slug

Otro detalle que descubrí sin querer es que WordPress espera que el dominio del texto coincida con el slug del plugin. En esta versión se arregló mediante cambios en los archivos de PHP, JS y de traducción.

Esto suele arreglar los típicos “¿por qué esto no se traduce si tengo el .mo?” o las inconsistencias que surgen cuando WordPress intenta cargar el dominio correcto.

Readme de JS Archive List mas claro

También se actualizaron los headers del plugin/readme (requisitos, licencia y license URI), pues ahora son requeridos y durante esta década no los había incluido. Así, el plugin tiene una mejor calidad y cumple con los lineamientos de los plugins que exige WordPress.

Más fácil brindar calidad: docs y setup de PHPUnit

Este es mi lado de profesor universitario hablando: si quieres que un proyecto sea sostenible, haz que sea fácil de probar. La nueva versión 6.2.0 incluye: documentación y script instalador para configurar la suite de pruebas con WordPress y PHPUnit

Esto reduce muchísimo la fricción al añadir pruebas, correrlas en CI y detectar regresiones antes de que algo llegue a producción. Probablemente agregue más pruebas en futuras versiones de JS Archive List.

Codex me ahorró horas

Aquí va mi confesión nerd: parte de esta actualización se benefició mucho de Codex para acelerar el trabajo “invisible”: revisar cambios repetitivos, mantener la consistencia con los estándares de WordPress y, sobre todo, acelerar la incorporación de chequeos de calidad (tests, estructura, convenciones) sin convertirlo en una semana entera de trabajo.

Eso sí, no reemplaza el criterio (eso no se delega), pero sí recorta brutalmente el tiempo entre “tengo que hacerlo” y “listo, quedó fino y revisado”.

Prueba JS Archive List y dime qué tal

Si todavía no lo has probado, este plugin existe para lo mismo que yo quería hace años: un archivo colapsable, limpio y configurable, y hoy, además, con soporte moderno vía el block de Gutenberg.

Pásate por la página del plugin, instálalo, juega con las opciones y, si te sirve, deja una reseña, reporta bugs o sugiere mejoras.

Eso es lo que mantiene vivo el software libre.

Deja un comentario

Cómo corregí una vulnerabilidad en mi plugin JS Archive List tras un reporte de WordFence

JS Archive List es un plugin que creé hace más de una década para mostrar archivos de entradas de WordPress en un formato más limpio y dinámico usando JavaScript (inicialmente era con JQuery). Pues hace unas semanas recibí un correo de un grupo de hackers y del equipo de Wordfence (correos separados) informándome de una vulnerabilidad en JS Archive List para realizar inyecciones SQL.

Para quienes no lo conocen: JS Archive List toma los años y meses archivados en la base de datos y permite generar un widget o listado que se navega sin recargar la página. Es sencillo, útil y, como muchas herramientas viejas, tenía una parte interna que había quedado congelada en el tiempo, de hecho ese código viene del fork original en el que está basado.

Cómo se descubrió la vulnerabilidad en JS Archive List

Hace unas semanas recibí un mensaje desde la plataforma de investigadores de WordFence. Ellos tienen un programa privado donde reportan vulnerabilidades a desarrolladores antes de hacerlas públicas, y me dieron un plazo de tres semanas para liberar un fix.

El problema estaba en algo básico, la forma de generar la consulta SQL. El plugin recibía un año a través de la API o URL para filtrar los archivos, pero ese valor venía directamente de la base de datos sin sanitización y se insertaba en la query. Resultado: era posible modificar la consulta enviando un año inválido, lo que abría la puerta a inyecciones SQL.

Nada glamuroso ni nada complicado. Pero sí peligroso.

Actualizando una década de código para usar $wpdb

El fix de la vulnerabilidad en JS Archive List estaba claro: había que actualizar una porción del plugin que llevaba más de diez años igual, adaptarla a las funciones seguras de $wpdb y garantizar que todas las consultas pasaran por sus métodos de preparación. Esto no solo eliminó la inyección SQL, sino que dejó la base para que futuras mejoras del plugin también sigan buenas prácticas. Y claro: ahora JS Archive List es más seguro que nunca. Debo admitir que solo en la última semana del plazo pude sentarme a corregirlo (cosas de la vida), pero una vez entré en modo mantenimiento salió bastante fluido.

Luego tuve que entrar al sistema de WordFence y anunciar que el problema estaba corregido en la última versión. Tanto el grupo de hackers como el equipo de WordFence revisaron y confirmaron que todo está bien para cerrar la alerta en el sistema mencionado.

Reflexión final

Este fue un recordatorio amable de que mantener software libre significa estar dispuesto a revisarlo, actualizarlo y cuidarlo. Si usas JS Archive List, te recomiendo actualizar a la última versión. Y si alguna vez te toca lidiar con reportes de seguridad, tómalos como una oportunidad para pulir tu código y ayudar a hacer Internet un lugar mas seguro para todos.

¿Te ha pasado algo similar? ¿Descubriste vulnerabilidades en tu propio software?
Me encantaría leer tus experiencias en los comentarios.

Deja un comentario

JS Categories List 4.0

Luego de 7 años tuve la oportunidad de dedicarle tiempo a mi plugin JS Categories List y poder actualizarlo para que esté al día respecto a los estándares de WordPress y de la web en general.

Listado de categorías de forma dinámica
El plugin muestra un listado de categorías expandibles

Durante este tiempo WordPress añadió Gutenberg, un editor visual que ahora se incorpora en cada instalación y poco a poco va tomando el liderazgo de como crear el contenido. Por este motivo los widget/bloques han migrado a ser hechos con una aplicación en React y que llame a entradas del API del sitio.

Eliminación de jQuery de JS Categories List

En estos 7 años el principal cambio fue lo innecesario de depender de jQuery. Su popularidad se debía porque está incluida en cada instalación y anteriormente ayudaba a manipular el DOM fácilmente debido a las limitaciones de los navegadores.

Pero actualmente no es necesario usarla: los navegadores ya permiten hacer nativamente mucha de sus funcionalidad, la librería requiere cargar contenido JS innecesario y los bloques de Gutenberg se realizan con React quien ofrece mucho mas.

Creación del bloque de Gutenberg

Primero fue mejorar el código fuente, cuya tarea mas que todo fue aplicar estandarización de código PHP, organizar mejor el código, rescribir partes mal hechas

Luego fue la creación del bloque de Gutenberg, tomé como base el código fuente de mi otro plugin recientemente actualizado y lo modifiqué para funcionar con categorías en vez de archivos.

Los bloques de Gutenberg usan React, así que me tocó rescribir el plugin desde el PHP que genera HTML a componentes JSX. La lógica es similar pero en esta migración pude hacer mejoras que luego apliqué a la versión de PHP.

Para facilitar futuras mejoras y ver que el código funciona, agregué pruebas jest a los componentes y así asegurarme que todo funciona bien. En futuros cambios, ahora tendré como probar los cambios y garantizar el correcto funcionamiento,

Animaciones en JavaScript

Una de las principales funcionalidades que ofrecía jQuery es de animaciones sencillas con simplemente llamar una función. Esta funcionalidad no está disponible en el JavaScript puro porque esas características se fueron agregando a CSS.

En mi plugin de JS Archive List, logré implementar las animaciones usando clases CSS pero no funcionan bien en algunos casos reportados por usuarios, sobre todo, cuando hay altura dinámica.

Por ello, para este JS Categories List decidí crearlas desde 0 en vanilla JS para que funcionen bien en cualquier escenario. Descarté el uso de clases CSS por el problema mencionado, ademas que es mas fácil de probar de forma automatizada.

Experiencia al actualizar JS Categories List

Aprendí mucho al rescribir mi código antiguo. Noté como ha evolucionado mi forma de programar a lo largo de estos años, cómo la tecnología cambia pero las bases de WordPress se mantienen y la retrocompatibilidad se respeta. Con razón este CMS es el mas usado en el mundo.

Pude pulir mis conocimientos de React, de pruebas automatizadas con Jest y aplicar mejores patrones en el código de PHP. También el resultado me permitirá actualizar con mayor frecuencia este plugin y ofrecer mejoras.

Si usas WordPress te recomiendo descargar e instalar mi plugin.

Espero que te guste y lo uses en tu sitio.

Deja un comentario

Comprobar si una pasarela de pago esta activa en WooCommerce

Si en WooCommerce necesitas comprobar si una pasarela de pago esta activa. Puedes obtener un listado de las pasarelas de pago (gateways) disponibles en el sitio con la función:

WC()->payment_gateways->get_available_payment_gateways();

El problema de esta función es que estas instanciando WooCommerce y en algunos casos, algunas pasarelas dejan de registrarse o se esconden por motivos de seguridad. Esto hace que fallen mas adelante cuando realmente deben mostrarse en el checkout. Además, si necesitas comprobar si una pasarela pago está activa en un momento donde no se ha cargado WooCommerce. Necesitas una alternativa a esta función

Comprobar si una pasarela pago está activa desde la base de datos

Una alternativa segura es consultar la información directamente desde la base de datos. Así no necesitas implementar o instanciar objetos. El costo de la consulta es mínimo y queda en caché para futuros accesos (si se usa $wpdb).

WooCoommerce guarda la información de una pasarela de pagos en la base de datos en la tabla options bajo el nombre «woocommerce_idDelGateway_settings». Si el id de tu pasarela es «pagos_con_tarjeta» entonces la información se guarda bajo el nombre woocommerce_pagos_con_tarjeta_settings.

Como la información se guarda en formato JSON. Sólo necesitamos contar el registro bajo el nombre anterior que tenga el valor enabled: true dentro del contenido del JSON.

Para ello hacemos la siguiente función que buscará si existe el valor o no:

function is_enabled($gateway_name) {
  global $wpdb;

  $query = "SELECT COUNT(*)  FROM $wpdb->options "
    . "WHERE `option_name` ='woocommerce_${gateway_name}_settings' "
    . "AND  `option_value`  LIKE '%\"enabled\";s:3:\"yes\"%'";

  $count = $wpdb->get_var( $query );

  return $count > 0;
}

Esta función dependiendo del contexto, puedes ponerla en el archivo functions.php o en el código de tu plugin. Puedes llamarla en cualquier momento ya que $wpdb se instancia temprano en la carga de WordPress.

¡Listo! Con esto podrás leer directamente desde la base de datos si comprobar si una pasarela pago está activa o desactivada. Sin afectar el funcionamiento de WooCommerce.

Deja un comentario