Saltar al contenido

Categoría: Desarrollo web

Code for the People: documental sobre la web abierta y WordPress

Navegando por las redes sociales vi que muchas personas anunciaban el lanzamiento de un documental sobre quienes han participado en el desarrollo de la web. Me llamó la atención, ya que hacía mucho tiempo que no se producía un contenido de este tipo, así que decidí darle una oportunidad. El documental se titula Code for the People y está dirigido por Bao Nguen. A lo largo de la obra se presentan las experiencias de varias personas que contribuyeron a democratizar la web, haciéndola más accesible y permitiendo que millones de usuarios pudieran crear y compartir contenido en Internet.

¿Donde puedo ver Code for the People?

Code for the People es un cortometraje de 20 minutos dirigido por Bao Nguyen. El mismo fue subido a Youtube y lo puedes ver . En él se realiza un recorrido por el pasado, el presente y el futuro de la web abierta. Además, plantea una reflexión sobre los desafíos que enfrenta el software de código abierto ante el creciente dominio de los monopolios digitales y el auge de los sistemas de inteligencia artificial de carácter propietario.

A medida que avanza el documental, es fácil notar que muchas de las personas entrevistadas están relacionadas, de una u otra forma, con el proyecto WordPress. Esto no representa ningún inconveniente para la narrativa, aunque, al investigar un poco más, descubrí que el documental fue patrocinado por Automattic. Aun así, ese patrocinio no resulta invasivo ni resta credibilidad al contenido, ya que el enfoque sigue siendo una reflexión sobre la evolución de la web abierta y la importancia del software libre en su desarrollo.

Code for the People | A Film by Bao Nguyen | Full Documentary

Espero que os haya gustado este documental. Aunque está centrado exclusivamente en la comunidad de WordPress, creo que resulta inspirador y muy motivador. Personalmente, me siento identificado con muchas de las personas que aparecen en él, y siempre es interesante conocer cómo ha evolucionado la web abierta a lo largo de los años.

Además, es innegable el papel que desempeñó WordPress al permitir que personas sin conocimientos técnicos pudieran formar parte de la web, facilitándoles la publicación y difusión de su contenido a través de Internet.

Espero que luego de ver Code for the People te animes y participes en ayudar a democratizar la web.

Hack the planet!

Deja un comentario

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

Class already exists en PHPUnit

Esta semana en el trabajo me topé con un error de Class already exists en PHPUnit. El cual me sorprendió porque no tenía mucho sentido:

Mockery\Exception\RuntimeException: Could not load mock class MiClase: class already exists

Entonces lo primero que pensé fue: “¡¿Cómo que ya existe si lo acabo de crear?!”. En mi trabajo estábamos creando una serie de pruebas unitarias (como siempre me ha gustado) para una nueva funcionalidad bastante grande, y usamos Mockery como herramienta para simular el comportamiento de clases y objetos. Si no lo conoces, Mockery es una librería para PHP que permite crear mocks, stubs y spies para probar clases de forma aislada, sin tener que depender de la implementación real.

¿Qué es un mock?

Tal vez te preguntes, ¿qué es eso de un mock? Bueno, imagina que tienes una clase llamadaServicioFactura que depende de ServicioCorreo para enviar correos. Pues resulta que cuando haces pruebas unitarias, no quieres que se envíen correos reales (que ningún usuario, inclusive el que está probando, reciba 30 notificaciones de prueba), tanto por costo, como por rendimiento y porque no se esta probando los correos. Entonces usas un mock de CorreoService que simula su comportamiento: no manda correos, pero finge que sí, y hasta puedes verificar si fue llamado o no. Bien útil. De esta forma, cuando se ejecuta la prueba, se ejecutará el mock e intercepta las llamadas y simula el comportamiento original.

Cómo solucionar: Class already exists en PHPUnit

Volviendo al error de Class already exists en PHPUnit, en el fondo, lo que pasaba es que tenia un conflicto con la instancia de un mock ya definido, es decir, habia definido un mock de una instancia de esa clase y aparte otro para la clase. . Si te estás preguntando qué es un mock de una instancia, son algo como esto:

$mock = mock('overload:' . MI_CLASE_MOCKEADA::class);

Cuando mezclas un instance mock con un mock normal, lo que en realidad estás haciendo es intentar redefinir la misma clase dos veces. Y eso ocasiona el error mencionado.

La solución a largo plazo es refactorizar ese código viejo para que nuestros tests no dependan de instance mocks. Pero la solución rápida y sencilla, es ejecutar cualquier prueba que use un instance mock en un proceso separado. PHPUnit hace esto muy fácil con una simple anotación:

/**
 * @runInSeparateProcess
 * @preserveGlobalState disabled
 */
public function pruebaQueIncluyeLosMockupsDeInstancia(): void
{
    // código con los mocks de instancia
}

Ya con eso deberías poder ejecutar la prueba, si necesitas mas información puedes ver la documentación oficial de PHP.Unit. Y si sigues con el problema, puedes probar con cerrar los mocks después de cada test con:

protected function tearDown(): void
{
    Mockery::close();
}

Palabras finales

¿Te ha pasado algo parecido? ¿Tienes otra solución o teoría? ¡Déjamelo en los comentarios, me encantaría leerte!

Gracias por leer hasta el final. Si te encontraste con el error Class already exists en PHPUnit y llegaste hasta aquí buscando respuestas, espero que esto haya sido útil.

Happy Testing! 🧪✨

Deja un comentario