Pero gracias a ese incidente, me topé con un par de cosas interesantes. La primera es que terceros desarrollaron un plugin para pidgin, que permite usar el chat de Facebook dentro de él. El paquete está disponible a través de un repositorio de Google Code.

Ya había visto la noticia sobre un plugin similar que estaba cocinando Duncan Mac-Vicar para Kopete, pero no le vi mayor interés hasta ahora, que ya había probado el de pidgin.

Durante la semana pasada, baje y compilé las fuentes (y sus dependencias) para probar. Así pude testear el funcionamiento del plugin. Por desgracia aun está muy inmaduro, pero ello no lo hace menos interesante.

Una de las dependencias kopete-facebook es qjson, una librería que extiende Qt para añadirle un JSON Parser, necesario para procesar los datos recibidos/enviados por la red de facebook.

Lamentablemente, ni kopete-facebook ni qjson estan empaquetados en ubuntu jaunty (qjson está en 9.10 karmic koala, pero karmic aun está en estado alpha). Tanto Duncan[1] como Flavio[2], solo ofrecen los paquetes fuente y un paquete para opensuse.

Entonces, luego que logré compilar ambas librerías se me cruzó por la cabeza…“Cualquiera puede hacerse un PPA, ¿y si lo empaqueto para kubuntu y lo subo?” Bueno, a eso me dediqué este fin de semana.

Gracias a una intensa tarde recordando como diablos empaquetar un .deb, y gracias a unas ayuditas de jci, finalmente hoy hace unos minutos, logré por fin empaquetar y subir sin errores ambas librerías.

Si alguien se anima a probar kopete-facebook, les dejo el repositorio: https://launchpad.net/~sirgon/+archive/ppa

Todavía no hay garantía de (1) que el paquete tenga todas las dependencias correctas y menos (2) que el plugin funcione completamente bien. De hecho, el mismo Duncan ya anunció estar en conocimiento de un bug que impide recibir mensajes que nos han respondido. Pero a medida que vea que avanza la cosa, volveré a empaquetar y subir.

Ojala tuviera tiempo para echarle un ojo más detallado al código.
Lo otro, es que mientras aun no está en jaunty tampoco, tal vez en poco tiempo más empaquete y suba Konversation para KDE4. Ese ya lo tengo compilado, pero me había dado flojera empaquetarlo.

Por alguna razón, siempre los pequeños desastres terminan resultando buena experiencias .

–
[1] Duncan Mac-Vicar, autor del proyecto Kopete.
[2] Flavio Castelli, autor de qjson.

A menos que contemos con una piedra rosseta (o mejor aún, conozcamos el lenguaje perdido), la única forma de decodificarlo es “al tanteo”.

Los últimos días, había experimentado una falla inusual en mi aplicación lectora de huellas. A veces guardando el “template” de la huella en la base de datos, quería guardar una segunda o tercera lectura, pero se seguía guardando el primero. Además, solo me identificaba 1 huella de todas las guardadas.

Volviendo al ejemplo que venía junto al kit de desarrollo, encontré el motivo, tanto del fallo como de mi confusión.

Mientras desarrollaba el código del lector de huellas en C#, encontré un método trabajaba con la base de datos, pero en un lugar donde no debía. Lo primero que hice hace meses, fue separar esa porción de código a otro archivo qu corresponde a mi capa de “Modelo”. La linea de la discordia fue la siguiente:

public int identify(ref int score, ref AxGrFingerXLib.AxGrFingerXCtrl grfingerx)
{
    GRConstants result;
    int id;
    SqlDataReader rs;
    TTemplate tptRef; // <= EL FALLO ESTA ACA
 
    // M&aacute;s c&oacute;digo...
}

El encabezado del método tenía un comentario que decía algo así como “compara el template de la lectura con todos los templates obtenidos desde la base de datos”. Por lo tanto, asumí que “TTemplate tptRef” significaba “Huella de referencia”. No sé que concepto de “medida de referencia” tuvo el programador del ejemplo, pero para mí, una regla o un peso es una unidad de medida de referencia. Es decir “Mi template se compara con todos los tuyos”.

Sin embargo, para el programador del ejemplo, “Huella de referencia” significaba “cada uno de los templates de la base de datos”. Es decir, “Mi template en cada vuelta del ciclo, será el mismo de la base de datos y se comparará con tu lectura”.

Ese simple cambio de significado, me echó a perder el código. Ahora después de mucho tiempo de haber hecho esos cambios, logré entender el funcionamiento de ese método solo leyendo el código, pero de no haber usado como “medida de referencia” el código del ejemplo sin modificar, me habría visto obligado a investigar a fondo “donde se quedaba pegado en la lectura de la huella”.

La moraleja es entonces, fijarse en todas las interpretaciones que pueda tener la documentación o los comentarios. Si somos nosotros los que documentamos, debemos evitar que un detalle tan pequeño pueda cambiarle todo el sentido.

Continuando con el retrasado proyecto del lector de huellas para el control de acceso, me topé con un problema de aquellos…

La aplicación actual de control de acceso funciona con SQL Server 7 sobre Windows 2000, una reliquia mal viviente. La herramienta de manejo de la base de datos (SQL Management) asociada a esa versión, es un verdadero misterio en funcionalidades. Por alguna razón, “Generar consultas SQL” a una base de datos, solo genera los modelos de las tablas, pero ni rastro de los registros. Finalmente no logré sacar esos datos, porque desde generar una copia de seguridad hasta volcar todo a un archivo de texto plano, generaba un lindo “error desconocido”.

No se quien lo logró, pero hoy recibí un DVD con los 900MB de tablas y registros de esas bases. El archivo era un copia de seguridad respaldo.bkp.

Lo primero que hice, fue tratar de jugar con él :p .

Un lugar donde explicar las cosas

Mientras no tengo un módulo de para blogear funcional en Gonium, no me queda otra que usar al enemigo (Wordpress). Lo cual no es del todo malo, sino justamente lo contrario.

La idea de tener un blog exclusivamente para el desarrollo de Gonium, me permitirá poder dejar en claro cuales son las ideas que se están implementando o se desarrollaran a futuro, allá en su propio lugar. Hay mucho por hacer, por lo tanto, mantener una bitácora de desarrollo (más que un precario Roadmap), espero me sirva mucho más.

Un detalle importante: el blog, el proyecto en Google en Code, los mensajes en Twitter, los commits de svn e incluso la documentación autogenerada del API, se mantendrán todos en idioma inglés principalmente.

La razón de esto es muy sencilla: universalidad. Aunque no me gusta la idea, lamentablemente en comunicaciones, el inglés es lo más universal. No por ser de origen chileno quisiera que solo algún amigo mío de acá lo ocupe. Espero que a todo a quien le sirva tenga la posibilidad de ocuparlo. ¿Quien me dice que alguien por ahí no estará ya husmeando el código? ¿Y si este alguien hablara en italiano? ¿O francés? ¿o alemán? ¿o chino?

Además, habiendo tenido experiencia en el proyecto GDT, noté como muchos usuarios, aun cuando en su mayoría se trataba de hispano-parlantes, simplemente no les gustó la idea de usar objetos y métodos nombrados en español. No entiendo estas mañas, pero se que son frecuentes y extendidas. De hecho, Eduardo Silva, en su charla de Monkey HTTP Daemon en el Encuentro Linux, mencionó haber tenido ese problema con los hispano-parlantes, así que decidió simplemente dejar todo, lista de correo, blog, documentación, etc, en inglés. Esta vez, adoptaré la misma idea y veré que sucede.

Por el momento, no espero una explosión de usuarios, ni mucho menos mientras la versión funcional brilla por su ausencia, pero sí espero ideas, comentarios y en general feedback. Ya me han estado preguntando cosas como “¿estás reclutando gente?”, lo cual es un alivio para esos minutos en que me cuestiono el “¿para que diablos estoy haciendo algo que solo me importa a mí?”. Por si acaso, sí estoy reclutando gente :B . ¿Desarrolladores en Zend Framework? Bienvenidos! Cualquier tipo de aporte será igualmente bien recibido, ya sea de parte de un PHPero, jQuerysta, CSSero, Traductor, Diseñador o Artísta son plenamente bienvenidos.

Confirmando lo que pensaba

Gracias a todo esto, tuve una ocurrencia del tipo “oh, ¿y si hago que el template de wordpress sea el mismo que el de Gonium?”. Con eso basto para ponerme a meter un poco de mano en la creación de un tema. Nuevamente confirmo lo que pensé hace mucho tiempo atrás acerca de wordpress, es espagetti.

Realmente es una de las APIs (si es que puede siquiera llamarse así a su “codex”) más espantosas que he visto. Gracias a que participo en tecnosquad.org y a que dedicamos un día para “la épica búsqueda de un tema nuevo”, fue como aquella tarde recolecte bastantes temas atractivos y los guarde “por si acaso”. Finalmente no encontramos nada que nos hiciera sentir ese “wow, es tema está pintado para tecnosquad”, pero igualmente la búsqueda me trajo un buen producto.

Ocupe uno de esos temas para codear el mio. Entonces fue cuando note la importancia de ciertos detalles.

El primero es sobre el tamaño de un tema. Por ejemplo los temas más “profesionales” suelen tener más archivos e incluso permiten agregar paneles de opciones al backend de wordpress. En esos archivos extra, los temas definen sus propias funciones, las cuales no tienen ninguna interfaz común, cada tema implementa sus cosas a su pinta. Algunos usaban clases/objetos, pero la mayoría solo funciones sueltas.

Otro detalle importante, es que aun cuando las funciones “del núcleo” para plantillas están documentadas, el solo hecho de leer un archivo fuente resulta caótico. Casi nada de pulcritud, incluso me atrevo a aventurar que ningún tema de los que termine bajando (y fueron muchos), ni si quiera tenían el código propiamente indentado.

Una de las primeras cosas que aprendí con el Zend Framework, fue el patrón de diseño “Two Steps” para plantillas, es decir, una plantilla “layout” que crea el esqueleto de la página, y luego se agregan los contenidos sobre este layout, que pueden provenir de otros scripts de vista. En wordpress, simplemente no existe tal cosa. No quise mirar más hacia adentro del código, pero lo que vi por fuera (las plantillas), me dan más ganas de “terminar” de una vez una versión usable de Gonium. Estoy seguro que sería una delicia para los diseñadores.

Más tarde, cuando ya pueda blogear tranquilo en Gonium, migraré el contenido y me desharé del wordpress. La idea principal está más viva que nunca: el objetivo es crear un administrador de contenido de propósito general, pero BIEN HECHO.

Consiste en el almacenamiento “seguro” de datos que viajan en un canal inseguro y se almacenan en un medio inseguro. Puntualmente, hablo de COOKIES. Cuando hablamos de protocolo HTTP(S), las cookies son el único “repositorio de datos” o almacenamiento persistente en el lado del cliente (navegador) con el que podemos trabajar.

En las cookies, podemos guardar las preferencias de un usuario (por ejemplo, el idioma que escoja, la última página que vió, etc…). Y el problema puntual con cookies: guardar la identidad del usuario para “recordar” su sesión.

El peligro esta en el como se guarda esta identidad. Lo bueno es que ya encontré un método que me convenció, y realmente es bastante “simple” como algoritmo. Lo que no fue simple fue la implementación.

La verdad es que no se como pretendía completar el primer punto de mi roadmap (Lista de control de acceso o ACL) sin tener primero un método decente de autenticación. Al menos ya di con una respuesta.

El problema de la autenticación por cookie

Para autenticar al usuario, necesitamos información de este que no diga “ah! este usuario es Perico Los palotes y no Pedro Juan Diego”. El problema se reduce entonces a “que dato guardar en la cookie, que sea único por cada usuario”.

El nombre de usuario o IDentificador

Una solución simple es, por ejemplo, guardar el nombre de usuario o un número “ID”. Esto sería una solución válida, de no ser por lo extremadamente inseguro que significa. Si guardo solo el nombre o id del usuario, cualquier persona podría crear una cookie en su navegador con la identidad de otra persona. Finalmente entraría a la web y ya estaría autenticado. Más que inseguro, es extremadamente estúpido.

El nombre de usuario + clave

Para obstaculizar un poco un eventual ataque, podríamos conciderar añadir un segundo campo, con la contraseña del usuario. Pero nuevamente, sería desastroso en términos de seguridad. Ahora la información de la sesión, estaría a la vista de cualquier persona que ocupe físicamente el mismo equipo. O peor, un atacante remoto que haya podido ver la cookie (vía malware o interceptando la comunicación). Este atacante podría iniciar la sesión por usuario y contraseña sin problemas.

Otra solución, consiste en encriptar la clave y desencriptarla en el servidor, pero solo sería una distracción, porque el atacante igualmente podría clonar la cookie y autenticarse, a pesar de estar encriptada la contraseña. Lo mismo pasaría si en vez de encriptarla, se contara con una segunda “clave”, que solo fuera válida por cookie. No sería posible iniciar sesión de forma clásica, pero si se podría directamente copiando la clave.

Entonces ¿que guardar en la cookie para autenticar al usuario? Hace años, cuando realizé esta pregunta en diversos foros, recibí como respuesta que no había solución perfecta, pero si quería hacer algo que ofusque un ataque.

Contrastar una clave aleatoria con una clave en la base de datos

Buscando una solución, llegue a una implementación de Cookies de Autenticación, consistente en un sistema de login. En esa implementación, se pone el enfasis de la seguridad en la IP del usuario. Pero obviando ese dato, el algoritmo combina el id de sesión de PHP, las cookies y la base de datos, de tal modo que entre esos 3 medios de almacenamiento se guarden “claves”, las cuales se contrastarán entre los 3 para autenticar los datos.

No es del todo malo, pero resta rendimiento, debido a que hace consultas extras a la base de datos y muchas comprobaciones.

Lo contraproducente del asunto, es que el diseño de este algoritmo impediría que un usuario guarde su sesión en más de un navegador, porque cada vez que se genere la clave aleatoria nueva, se pierde la validez de las cookies guardas antes en otros navegadores. Peor aún, si incluímos la IP como un dato para comprobar la validez de la cookie, no servirá de nada con usuarios que tengan conexiones a internet con IP dinámica.

¿Entonces, el problema tiene solución?

Una solución elegante

Leyendo más acerca de este problema en general, mirándolo desde afuera de la visión cezgada de PHP, logré encontrar un paper muy interesante (solo 3 páginas). Parte planteando las mismas interrogantes y falencias sobre otros algoritmos como los que me había planteado, con la diferencia de que propone soluciones a cada uno de los problemas y los combina en un solo algoritmo. Más interesante aún, es que el paper describe el método completo, pero no se ciega en un lenguaje en particular donde implementarlo (navegando encontré incluso que fue implementado en python).

Por si el hecho de que los autores del paper son doctores en computación y expertos en criptografía fuera poco, una de las cosas que me dio confianza (aunque suene burdo), es que el mismo wordpress y otros sistemas estarían usando este método de autenticación por cookies.

Haciendo otra busqueda, me tope con alguien que lo implemento en PHP, y además implementó un adaptador para Zend_Auth.

Finalmente, tomé prestado el código de ambas clases, la manejadora de cookies seguras y la adaptadora para Zend_Auth), y las incorporé en mi proyecto.

Arregle uno que otro defecto que tenían:

• Ya no requiere mcrypt (que a veces no está instalado en los hostings). La característica de alta-confidencialidad es opcional y funciona solo con mcrypt activado, sino por defecto usa el modo de baja-confidencialidad.
• El dato de entrada debía ser un string. Ahora puede ser cualquier dato soportado por php, excepto “recursos”. Es decir, se pueden almacenar incluso objetos.

Hay una mejora que aún no implemento, que consiste en aplicar un hash al campo “username”, de esta forma, aumenta un poco más la confidencialidad del usuario, debido a que un administrador o un atacante no podría saber exactamente “quien fue el que inicio la sesión en el sitio” alguna vez, tan solo mirando las cookies. De todos modos, la identidad y rol los guardaría en el campo “data” serializados y codificados (y si es posible, encriptados también).

Y para rematar… ¿PHP Bug?

Como en prácticamente todos mis desarrollos, me he topado con Expedientes X. En esta ocasión, descubrí un comportamiento medio curioso con la serialización de obejtos. La serialización de variables permite convertir el valor y el tipo del dato (aunque sea compuesto como un array o un objeto) en una representación “almacenable” (en este caso, una cadena de texto).

Antes, no había tenido problemas con esto, pero ahora, para implementar el algoritmo de Cookie Segura, me vi forzado a usar serialización. Lo que no comprendo del todo, es porque al serializar objetos con atributos protegidos o privados, aparecieron unos caracteres raros entremedio. Curiosamente al pasar la misma cadena por otras funciones (como base64_encode/decode y las mcrypt), finalmente obtenia la misma cadena serializada, pero esta vez limpia de esos caracteres raros.

Extrañamente, no provocó ningún efecto adverso al deserializar los datos, por lo tanto, conservaban su integridad como era esperado.

Lo malo del asunto, es que el algoritmo de cookies seguras, requiere usar el campo “data” guardado en la cookie para formar la “llave” que comprueba la validez de la cookie. Si la cadena obtenida al desencriptar el dato de la cookie retorna “limpio”, entonces obviamente no concuerda con la cadena “sucia” que formo la llave inicial, y por lo tanto resulta en una cookie inválida, aún cuando el dato estaba bueno.

Si alguien desea probar si “su php” también tiene hipo, pueden probar este sencillo script.

class data
{
   public $a = '123';
   protected $b = 'abc';
   private $c = 'xyz';
}
 
$data = new data();
var_dump( $data ); // Can you see a fail?

En algunos casos, al parecer la salidad es correcta, es decir, sin ningún caracter raro metido entremedio. En otros casos (como el mío y otros más que me ayudaron comprobándolo), sí aparecían bichos en la salida. Una de las sospechas, recaen en que los que tuvimos la falla, estaríamos ocupando un “locale” en español en el sistema, encambio los que no tienen el fallo, usaban su “locale” en inglés. Espero (nuevamente) que el futuro motor de PHP6 deje de una vez de ser tan sencible a los cambios de “encoding”, tanto por el idioma del sistema en que corre, como por los scripts de entrada y por el texto plano de salida.

No se en realidad a que se debe esto, incluso sospeche que esto se trataba de un bug en ubuntu, pero finalmente resultó no ser tal.

Finalmente, mi “workaround” consistió en modificar aún más el algoritmo, de tal modo que la llave la formé con un hash del objeto serializado, en vez del objeto serializado por sí solo. Esto agrega unos cuantos milisegundos y operaciones extra (despreciables en todo caso), pero al menos logré “universalizar” el mismo script, que era el objetivo primario.

Al menos, creo que aprendí bastantes cosas tratando de resolver este poblema.

(*) Talla (español chilensis): dícese de broma o humorada

Aprovechando eso, subí una copia más reciente.

Hace unos días agregué al trunk del repositorio, una copia propia del proyecto zend-framework-datagrid, con la diferencia de que mi copia permite traducirlo con Zend_Translate y los comentarios están corregidos. También corregí unos warnings menores. Además le cambié el prefijo a las clases de “Core_” (originalmente en zf-datagrid) a “Rox_”, para darle concordancia a mi estructura de directorios. Podría decir entonces que es un pequeño fork :B

También agregué todo jQuery UI al directorio público. Una ejemplo de esto es la pequeña demostración con el efecto acordeón que le agregué al widget de Login.

Y por último, agregué un directorio con XML’s en formato docbook, para poder usarlos en conjunto con la documentación creada con phpDocumentor.

Espero tener una documentación un poco más completa más adelante.

Entre ayer y hoy, logré romper el segundo objetivo del Roadmap inicial de Gonium, consistente en crear la arquitectura modular para el Backend administrativo.

Ahora, la aplicación cuenta con 2 sistemas modulares independientes, uno para el Frontend (el sitio visible para todo usuario) y otro para el Backend (donde solo usuarios con privilegios pueden modificar cosas).

Esto significa, por ejemplo, que el módulo “user” que puede ver un usuario corriente (donde podrá modificar su perfil y esas cosas), será distinto del módulo “user” del administrador (donde se podrá crear/borrar/modificar cuantas usuarios).

Para dejarlo plenamente funcional, aún falta crear los módulos administrativos (así como los de usuario corriente), pero al menos, la arquitectura de directorios y bootstraping ya están adaptados para trabajar de esta manera.

Implementación

La técnica utilizada, consistió de los siguientes pasos:

Separar el bootstrap de Frontend del boostrap del Backend

Se creo un admin.php en el public_html, al mismo nivel de index.php, el cual carga el Core/boostrap.php pero cambiando el Environment a ‘Admin’.

Esto significó modificar las reglas de .htaccess para redirigir las peticiones que pasaran por la url admin/ a admin.php

Crear clases “inicializadoras” para cada Environment distinto

Esto debido a que ciertos plugins básicos y configuraciones especificas del Frontend no tienen sentido en el Backend (y los futuros de Backend no tienen sentido en el Frontend).

Cambiar la estructura de directorios

Casi vuelvo a dejar la embarrá con la copia de trabajo, pero finalmente lo salvé. Se tuvo que armar una nueva arquitectura de directorios para alojar los módulos administrativos. Aprovechando eso, también se movieron los módulos básico del Frontend y el controlador de errores, los 3 ahora son subcarpetas de /application/Core/Module. Esto fue pensado debido a que las clases controladoras son las única que no respetan el codding-standar de usar prefijos por cada carpeta, para separarlas como si fueran distintos namespaces. No lo necesitan tampoco, porque estas clases jamás se deberían cargar como librerías (al estilo de Zend_Loader).

Separar el controlador de errores del Frontend

Ya tenía implementado un controlador de errors, que despliega por pantalla cualquier Exception disparada durante el proceso del dispatcher. El problema es que este controlador estaba sujeto al módulo “default” del frontend, por lo tanto, no se podía usar desde el backend directamente. Se resolvió separar este controlador de ambos directorios, dejandolo independiente, y siendo este agragado al “Front Controller”. como una carpeta independiente. Este controlador DEBE estar disponible en todos los ‘Environments’.

Agregar un enrutador especial para el Backend

Había estado trabajando con un enrutador corriente como lo es el Zend_Controller_Router_Route con una regla sencilla. Pero no me percaté que el enrutador predeterminado, usaba internamente (y por defecto) un enrutador llamado Zend_Controller_Router_Route_Module. Cambiandolo a ese, logré crear un enrutador 'admin' que funciona bien en la estructura modular separada del backend.

Pensé que sería más sencillo… D:

No me quedo otra que hacerlo por esta vía, ya que las rutas se resuelven en tiempo de “dispatching”, por ende no puedo configurarlas despues que la aplicación ya empieza a correr.

Si alguien conoce alguna solución más limpia, favor de comunicarse conmigo, sino pruebenlo, ya hice el respectivo commit al repositorio del proyecto.