Sí sí, otra vez vuelvo sobre el tema, porque realmente es de nunca acabar. Bueno, es la fuerza que tienen las leyes comprobadas de la ciencia.

Como en muchas otras empresas, trabajamos con servidores de prueba y de producción, separados. En uno de ellos se lleva a cabo el desarrollo y testing de las aplicaciones y luego de superadas ciertas etapas se “sube” a producción, en donde el código tiene su feliz vida dentro de la aplicación real que navegan los usuarios finales.

Hoy quiero contar algo que me pasó en estos días, al intentar subir unos cambios a una aplicación, alojada en un servidor que también me toca administrar. Entre los servidores de desarrollo y producción, en este caso, hay algunas diferencias, pero no demasiado sustanciales. De hecho, no afectan para nada el desarrollo y, casi el cien por ciento de las veces, todos los cambios se limitan a una simple transferencia de archivos.

Hoy fue la excepción. En ciertos casos de uso… bueno, con algunas urls, parte de la aplicación dejó de funcionar. Vueltas y vueltas, configuración de php, investigar las reglas del mod_rewrite, url encodings… ¿qué está sucediendo?

En desarrollo todo iba perfecto, pero en producción, con ciertas combinaciones de caracteres en la url, se obtenian errores 400 alias “bad request” que, junto al 500 (”internal server error“), formaría algo así como la pantalla azul de la muerte para Apache.
Como casi todos los problemas insondables del universo que alguna vez fueron resueltos (y seguramente lo mismo pasará con los que no lo fueron aún), di en la tecla por una suerte de inspiración momentanea, o iluminación. La fuente del problema era una regla del mod_security.

Claro! En desarrollo no lo utilizamos tan severamente como en producción, y el error se veía tan genérico que ni se me ocurrió. Se me ocurrieron decenas de otras causas antes de dar con la correcta.

Ahora bien: ¿qué tiene que ver con el título de mi post? ¿Seguridad y usabilidad? ¿Dónde?

La usabilidad no es sólo de los usuarios. Hace rato que observo diariamente lo que yo llamo “usabilidad del código“, o como quieran llamarle. Se trata de la facilidad de edición de un programa, por ejemplo. En este caso, la facilidad de subir cambios a un servidor de producción.

Como en producción (o live) tenemos reglas más severas, a veces se producen este tipo de cosas inesperadas.

Para dar otro ejemplo un poco más simple: transferir archivos por ssh es un poco (mínimamente) más incómodo que por ftp liso y llano. Pero, por seguridad, nos molestamos un poco más y lo hacemos bien.

Si quisieramos que todo fuera más cómodo, deberíamos bajar nuestros niveles de seguridad. Mientras que si queremos sistemas más seguros, perdemos un poco de comodidad diaria.

La comodidad diaria no es otra cosa más que la usabilidad o, en otras palabras, esos cachitos de felicidad imperceptibles para nuestra consciencia que alguna parte de nuestro cerebro disfruta cuando todo va bien.

Y la seguridad no es otra cosa más que ponerle trabas a esa comodidad. Porque para estar más seguros tenemos que pensar más a través de todo el proceso, y pensar no nos resulta cómodo.