Para hacerlo funcionar no se necesita más que copiar y pegar en un nuevo archivo .php el código que se mostrará a continuación, subirlo a la carpeta wp-content de WordPress, y activarlo desde el dashboard.

< ?php /* Plugin Name: Block Bad Queries */
 
if (strlen($_SERVER['REQUEST_URI']) > 255 || 
	strpos($_SERVER['REQUEST_URI'], "eval(") || 
	strpos($_SERVER['REQUEST_URI'], "base64")) {
		@header("HTTP/1.1 414 Request-URI Too Long");
		@header("Status: 414 Request-URI Too Long");
		@header("Connection: Close");
		@exit;
} ?>

En pocas palabras, lo que hace el script es revisar todas las peticiones que se hagan al servidor y bloquear aquellas que excedan 255 caracteres, así como también las que contengan eval( o base64 dentro del string del request.

Y como dicen que una imagen vale más que mil palabras un video vale más que un millón de palabras, a continuación pongo un screencast de cómo funciona Compass.

No discuto su valor como feature, sin duda alguna el permitir tener un control de versiones de los posts y brindar la posibilidad de recuperarlos en caso de que por equis razón se pierda es algo primorial. Pero, a mi en lo personal, que no he utilizado hasta la fecha ninguna revisión y sin embargo se han ido acumulando filas de revisiones en mi base de datos más que ser una solución es una inquietud —soy demasiado quisquilloso con eso de tener limpia la BD.

Es por esa razón que decidí desactivarlas y para todos aquellos que al igual que yo sienten la espinita o también son quisquillosos les comparto la forma en que lo hice. Es bastante simple.

Primero, para borrar todas las revisiones de nuestra base de datos hacemos el siguiente query en MySQL.

DELETE FROM wp_posts WHERE post_type = 'revision';

Con esto habremos eliminado todos los posts del tipo revision de la tabla wp_posts. Ahora, para deshabilitar el guardado automático de las revisiones tenemos que modificar el archivo wp-config.php agregando lo siguiente:

define(’WP_POST_REVISIONS’, false);

Añadiendo la línea anterior deshabilitaremos completamente las revisiones automáticas y no se guardará ninguna de aquí en adelante. No obstante, si no quisieramos deshabilitarlas por completo sino solo establecer un límite de revisiones a guardar podríamos hacerlo de la siguiente manera:

define(’WP_POST_REVISIONS’, 3); // 3 es el número de revisiones a guardar

Así le indicamos a la configuración que el límite de revisiones a guardar por post son únicamente tres y no más, por lo que únicamente guardará las tres más recientes.

A mi me funciona a la perfección y a partir de ahora ya no tengo revisiones de posts amontonadas en mi base de datos.

Yendo al grano, la virtualización es un proceso que consiste en correr uno o varios sistemas operativos virtuales sobre un sistema operativo “real” (por llamarle de alguna forma) que funciona como nuestro host, de forma que podamos utilizarlos independientemente de su filesystem y otras características propias de cada uno. Todo esto sobre un mismo hardware que les provea de las capacidades y/o servicios necesarios para su funcionamiento.

¿En qué nos beneficia esto? En primer lugar, tener diversos sistemas operativos aislados los unos de los otros y que sean totalmente funcionales. En segundo lugar, nos permite aprovechar más del 20-30% de los recursos de nuestros servidores —hay estadísticas demuestran que es el promedio de aprovechamiento que se les da a los servers. Y bueno, además, virtualizar ahorra espacios, costos, energía, y sobre todo, es eco-friendly.

Pero bueno, lo que más importa en esto es la seguridad, y en cuanto a ella dentro del mundo de la virtualización existen diversos mitos que se creen. Que si es esto, que si es lo otro, que sus ventajas, sus desventajas, etcétera.

En mi opinión existen tres mitos importantes con los que la mayoría entramos en confusión y comúnmente nos quedamos con una idea errónea. Los pongo a continuación:

1. Sólo ocupo agregar un patch al OS/kernel del host
   De entrada muchos nos vamos con la idea de que al estar utilizando máquinas virtuales (VM, virtual machines) no es necesario protegerlas con antivirus, firewalls, etc., y que lo único que importa es el OS host. Sin embargo las cosas no son así. Es necesario pensar como si nuestras VMs estuvieran corriendo sobre una máquina propia y no sobre un host; en otras palabras, verla como cualquier otra máquina en la red la vería. Hay que equiparlas con las herramientas de seguridad necesarias y darles mantenimiento como cualquier otra instalación de un OS.
2. Con que proteja mi máquina host mis máquinas virtuales estarán protegidas
   Hay que tener en cuenta la existencia de los rootkits “virtuales” que de momento no representan gran peligro para nuestras máquinas virtuales y que pasan desapercibidos, pero como cualquier otro malware, una vez que alguien les echa el ojo y lo explota, las cosas se complican bastante.
3. Los archivos de los discos duros virtuales son seguros por default
   No sabemos de dónde viene exactamente la máquina virtual que vamos a utilizar ni que tantos patches de seguridad tenga instalados. Al igual que el dinero, pudo haber pasado por muchas manos y nosotros no estaremos nunca cien por ciento seguros de que no es una VM alterada/corrompida. Lo mejor, aunque tampoco es absolutamente infalible, es crear nuestros propios built-ins y no dejar que nadie meta mano a la instalación; eso al menos nos dará un mayor nivel de seguridad —al menos estamos seguros de que no nos haremos jugadas chuecas a nosotros mismos, jeje.

Para terminar quiero enlistar algunas acciones clave que recomienda el Microsoft Trustworthy Computing Group para brindar mayor seguridad a nuestros ambientes virtualizados:

• Reducir la superficie de ataque en el host.
• Siempre utilizar lo menos posible privilegios de acceso.
• Auditar la instalación, el mantenimiento, el contorl, y el acceso a las VMs.
• Proteger los archivos de configuración y de disco de las máquinas virtuales, incluyendo los respaldos.
• Utilizar redes virtuales (VLANs) para aislar las máquinas.

Es fácil desacreditar una aplicación por su interfaz —ya saben, juzgar un libro por su cubierta— pero analizar las fallas, definir cuáles son las problemáticas que tienen, y ofrecer posibles soluciones a estas no lo es tanto.

¿De dónde viene todo esto?

Bien, pues hace un par de semanas me encontré con un artículo escrito por Matthew Paul Thomas titulado Why Free Software has poor usability, and how to improve it en el que habla sobre la lenta evolución que se ha dado en cuanto a la usabilidad durante los últimos seis años y los principales obstáculos a los que se enfrenta no sólo el software de código abierto, sino también todos aquellos proyectos de software en los cuales su equipo de desarrollo está integrado por personas que participan de forma voluntaria, es decir, el volunteer software (como él mismo le llama).

Como el free software es el ejemplo más característico de la participación voluntaria, el autor se basa en el para resaltar los problemas esenciales según su perspectiva y los enlistó junto con sus respectivas soluciones. Me tomé la libertad de traducir aquellas que me parecieron más relevantes y con las cuales concuerdo; las pongo a continuación.

1. Los proyectos de software libre no cuentan con grandes incentivos económicos con los cuales retribuir a sus desarrolladores, a diferencia de los proyectos de software propietario; por lo que la única forma en la que los participantes pueden obtener ganancias financieras es a través de las donaciones que hagan los usuarios del software.
2. La poca intervención de buenos diseñadores en los proyectos gracias a que muchos programadores prescinden de ellos y creen ser capaces de realizar actividades de diseño.
3. No existe un proceso establecido de usabilidad ni un documento de especificaciones sobre el cual se puedan basar los diseñadores para aportar sus ideas y sugerencias al proyecto, por lo que los desarrolladores prestan más atención a fallas técnicas que de usabilidad.
4. No se cuenta con el tiempo suficiente ni con las personas indicadas para realizar pruebas de usabilidad que ayuden a comprender la interacción de los usuarios con la aplicación y sus hábitos de uso.
5. Codificar antes de diseñar, lo cual es muy común entre los programadores. Ellos simplemente prescinden del prototipado, del wireframing, y de todos todos los demás procesos de diseño necesarios “tediosos” e “irrelevantes” y se pasan directo a la codificación del software.
6. Proyectos que no cuentan con un diseñador líder que se encargue de canalizar las aportaciones de todos los demás diseñadores que colaboran en el proyecto no tendrán buenos resultados. Es necesario asignar el rol de lead designer para evitar la desorganización y el descontrol.
7. Tomar como referencia a productos famosos —aunque no necesariamente exitosos— que quizás hayan fallado en sus interfaces de usuario y cometer los mismos errores que ellos al intentar imitarlos.
8. Los desarrolladores son al mismo tiempo usuarios, y aprovechan para meterle cuanta característica se les ocurra, lo cual no está mal si se está desarrollando una aplicación de uso más técnico y especializado. Pero si se está desarrollando una aplicación de uso general y orientada a usuarios nuevos y no tan especializados, el software termina siendo bastante complejo y lleno de opciones que lo único que consiguen es ahuyentar al usuario al no saber qué hacer con tanto.
9. No se corrigen los pequeños detalles y se van quedando versión tras versión sin ser arreglados.
10. La falta de comunicación hablada y “más directa” (e.g.: Videoconferencia, VoIP, pizarra virtual, etcétera) entre los desarrolladores que les permita expresar de una mejor manera sus ideas y explicarlos de forma más detallada. Esto viene a colación debido a que generalmente en los proyectos de software libre los participantes viven en ciudades, países, y continentes diferentes.

Me parece que básicamente lo que falla es la organización y la buena definición de roles. Eso de querer hacer todo no lleva a nada bueno; las responsabilidades hay que delegarlas de tal forma que aquellos que las vayan a llevar a cabo sean los indicados y estén acorde al pérfil requerido. También es necesario contar un proceso de diseño y desarrollo bien definido de tal manera que tanto diseñadores como programadores sepan específicamente qué hacer y cómo hacerlo coexistiendo en un ambiente en el que puedan realizar sus tareas sin afectar el trabajo del otro.

Estoy seguro que son más las razones del por que la usabilidad en el software libre está mal, pero las esenciales son esas.

Por último, aclaro que las problemáticas que mencioné sólo son las que consideré más importantes. Si estás interesado en conocer cuáles son las demás y las soluciones que el autor tiene para cada una, puedes consultar el post original.