FirePHP está compuesto de 2 partes, una librería PHP (puede ser usada en versión orientada a objetos o en funciones). La otra parte es una extensión para Firefox (también hay otras extensiones de terceros para otros navegadores, como Google Chrome), que a su vez extiende la funcionalidad de la ya conocida extensión Firebug.

¿Para que sirve?

Firebug añade un panel donde se puede llevar control de varios tipos de error que son detectados por el navegador, sobre todo en tiempo de ejecución como lo es con javascript de las páginas web o también de las mismas extensiones de Firefox.

FirePHP añade algo más. Por el lado de la librería, Firebug es capaz de enviar información de depuración a través de las cabeceras HTTP y no en el contenido (como lo hace el reemplazo de la gestión de errores nativa de PHP que añade Xdebug). Esto tiene varias ventajas, por ejemplo:

• Evita que al desplegarse errores sobre el HTML de un sitio, este se descuadre su diseño, o debido al diseño, no pueda verse bien el error en ciertos casos.
• Evitar corrupción de datos cuando PHP genera salidas que no son de texto plano, por ejemplo al generar un PDF dinámicamente o imágenes (con php_gd2).
• Al hacer peticiones por ajax, donde generalmente uno “no ve” lo que está llegando (con Firebug se puede ver), y por lo tanto tampoco se ve si la salida venía con errores entremedio.
• En la misma linea de los 2 puntos anteriores, evita que se corrompa una salida en json o xml al hacer peticiones ajax que vengan con errores.

Por el lado del cliente, añade un filtro a Firebug para detectar estas cabeceras y desplegarlas en la Consola de Firebug.

Además, con un pequeño “hack”, se pueden redirigir TODOS los errores estándar que salen por pantalla, a las cabeceras, simplemente con un script (en PHP).

Hermoso, ¿y como lo hago funcionar?

Simple.

En el lado del cliente, instalar las extensiones Firebug y FirePHP.

En el lado del servidor, solo hace falta bajar y e instalar la librería en alguna carpeta que este dentro del include_path de PHP. Eso se puede ver en el php.ini o vía phpinfo().

Listo. Ahora cada vez que se quiera exponer una variable o dato de PHP por la consola de Firebug, es cosa de llamar una función (o método) que provee FirePHP. Al ejecutar el script se verá ese dato en la consola.

Redirigir Errores a las cabeceras

Ahora si además queremos que cualquier error (E_WARNING, E_NOTICE, por ejemplo) se vean a través de la consola de Firebug, entonces además hace falta un hack.

Primero es necesario crear un script php con el siguiente contenido:

registerErrorHandler(
            $throwErrorExceptions=false);
$firephp->registerExceptionHandler();
$firephp->registerAssertionHandler(
            $convertAssertionErrorsToExceptions=true,
            $throwAssertionExceptions=false);
 
ob_start();

Se debe añadir en la configuración de php.ini, en la directiva auto_prepend_file, la ruta directa a un script, llamemoslo “firephp.php”. Supongamos que está en c:\www\firephp.php quedaría así:

auto_prepend_file = “c:\www\firephp.php”

En mi estación Linux/Mac lo tengo así:

auto_prepend_file = “/Volumes/Documentos/devel/www/firephp.php”

Pruebas

Nada especial. Es cosa de crear algún script y añadirle algo como:

$var = array ('uno', 2, array('sadf', 'qwerty'), 'tres' );
FB::log($var);

y para probar errores:

trigger_error('HOLA, ESTE ES UN FALLO INTENCIONAL');

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.

Afortunadamente no era fatal, ya que igualmente podía modificar los parámetros del sitio sin mayor inconveniente. Pero es molesto ver que algo no está bien, menos en un sistema grande como lo es Joomla.

El error me indicaba que había un archivo XML que no se estaba “parseando” adecuadamente, pero no me decía cual archivo ni cual error tenía.

Entonces decidí bajar una copia de seguridad del sitio completo, y replicarlo en mi máquina local para averiguar el error. Recordé que en linux existen miles de aplicaciones por consola, lo suficientemente poderosas para parsear y validar los XML’s de mi sitio.

Ya tuve una experiencia grata con el comando find. Pero me faltaba el comando para validar un archivo xml. Buscando encontré que posiblemente el comando xmllint me podría servir. Aunque finalmente no me ayudó, revelé un pequeño detalle que no me esperaba.

xmllint tiene una opción para validar, pero para realizar ese trabajo, requiere que 1) el archivo XML defina un DTD o 2) se le pase por parámetro. Probando sin usar un DTD por parámetro: probé lo siguiente:

find . -name "*.xml" -exec xmllint --noout --valid "{}" \;

Lamentablemente, el resultado no fue lo que esperaba. TODOS los XML salvo uno, eran inválidos, debido a que NO TENÍAN definido el DTD. Gracias a ese archivo que sí lo tenía, descubrí que joomla TIENE en su sitio un archivo DTD para que los desarrolladores lo incluyan en sus XML de configuración. De esta forma, el desarrollador obliga a que sus archivos XML tengan la estructura que el sistema requiere.

Lo peor… ese único archivo válido, era de un plugin de terceros y no de los desarrolladores oficiales. Es decir, los desarrolladores oficiales de joomla NO RESPETAN sus propias reglas al escribir el código.

Finalmente, xmllint no era lo que estaba buscando, ya que solo debía comprobar cual era el o los archivos mal formados (etiquetas mal cerradas, mal anidadas, …). Como no sabía, consulte en una lista de correo (una de las que tengo en la lista de comunidades), donde me dieron la solución: xmlwf.

Simplemente cambié el comando anterior por el siguiente y asunto arreglado:

find . -name "*.xml" -exec xmlwf "{}" \;

Encontré los culpables (eran 2), los corregí y di por terminado el asunto.
Pero me quedé con el sabor amargo de la despreocupación que los desarrolladores de Joomla han tenido en un detalle tan simple. ¿Que confianza me dan para cuando aparezca una nueva actualización del sistema?

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 .

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 . ¿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

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.