Ahora Gesbit guarda todas sus "cookies" (en realidad un par de ellas, una relacionada con el tema, que guarda datos de un "comentarista" y otra, más importante, relacionada propiamente con la autenticación de un usuario) usando la "bandera HttpOnly", disponible en PHP 5, pero, que, yo no estaba utilizando, siendo que uno de los requisitos de Gesbit es contar con PHP 5. Esta "bandera" impide que código en el cliente (Javascript) pueda acceder al contenido de la "cookie" en cuestión.

Como las cookies de que hablo no se leen desde el cliente, tiene todo el sentido del mundo usar esta opción a la hora de guardar las cookies, evitando en lo posible "ataques" que vinieran por ese lado. Pero he llevado a cabo un cambio todavía más interesante, relacionado con la propia clase GbUser. En efecto, hasta ahora Gesbit guardaba dos cookies para mantener a un usuario autenticado. En una de ellas guardaba una especie de "estructura" cifrada, y en otra el login de usuario "en claro".

Pues bien, esto no tenía ningún sentido. Es preciso contar con el login de usuario "en claro", dado que el funcionamiento de la clase GbUser implica conocerlo, para poder autenticarlo en una segunda instancia (después de haber comprobado en una primera que el usuario puede ser un usuario autenticado). Ahora bien, ¿por qué guardarlo en claro en una cookie? El cambio ha consistido en guardar en una sola cookie todo lo necesario, incluyendo el "login" de usuario, debidamente cifrado.

Pero, un momento, ¿cifrado? En realidad la única cookie que se utiliza actualmente, guarda en una especie de estructura varios datos del usuario. Pero, lo que se guarda en la cookie es el resultado de "serializar" dicha estructura y obtener su "base 64". Esto quiere decir que, en cierto modo, el login sigue estando en claro, sólo oculto tras la "base 64" y la "serialización", pero, al menos no se muestra de buenas a primeras en la cookie de marras. Y ahora además la cookie no podrá ser leída desde el cliente.

Por no decir que al cabo lo que se obtendría sería el login en claro, pero, no su contraseña, que, por supuesto, no se guarda en claro en la "cookie", más aún, se guarda el resultado de cifrar su "hash" correspondiente. He complicado esto también un poco, aunque, al hilo de lo que escribo me pregunto si convendría cifrar el login de usuario, de modo que luego pudiera descifrarse y comprobarse adecuadamente. ¿Qué quiero decir con esto?

En efecto, ciertos datos de la estructura de la "cookie" se cifran, pero, se utiliza una función "de un sentido", que, no permite descifrar los datos. Únicamente se permite luego comparar los datos "en claro" con su correspondiente "cifrado", de modo que se sepa si coinciden o no. Lo que se me ocurre al hilo de escribir esta entrada es usar algún algoritmo de cifrado que permita después descifrar el login, de modo que el login no se guardaría en claro en la cookie de inguna manera.

Para esto viene bien usar cierto "hash" que Gesbit obtiene a partir de la ruta en que está instalado. Este "hash" se utiliza ahora para cifrar (de una vez) ciertos datos del usuario para guardarlos en la cookie correspondiente, y este mismo hash podría utilizarse también como "salto" (o clave) para el algoritmo de cifrado que digo que acaso no estaría demás utilizar. Desde luego, con los cambios hechos, creo que algo se ha ganado, pero, igual esto último a que me estoy refiriendo no esté para nada de sobre. ¿Tú cómo lo ves? Habla ahora o calla para siempre. ¬¬

PD. Creo que se me ha olvidado comentar otro cambio "menor" en relación con lo que he tratado en esta entrada: ahora no podrá asignarse a un usuario (ni cambiar uno la suya propia) una contraseña que contenga o sea igual que el login de usuario en cuestión. Un pequeño paso para el hombre, pero, un gran paso para Gesbit. ;)

Efectivamente, se mostraban las últimas entradas de la bitácora, los últimos comentarios y unas cuantas "estadísticas" del sitio, además de unos "enlaces rápidos", que, son los únicos que quedarán a partir de ahora. Hay que pensar que estos "enlaces rápidos" han sido siempre considerados útiles, puesto que permiten varias cosas, justo cuando son necesarias: optimizar la base de datos, moderar comentarios y borrar el caché de contenidos de Gesbit. Estos enlaces se muestran ahora en el Widget "Enlaces rápidos", únicamente cuando son necesarios, es decir, por ejemplo, el enlace para moderar comentarios sólo se mostrará si realmente hay comentarios esperando moderación.

El Widget de enlaces rápidos permite también mostrar u ocultar el resto de Widgets del escritorio de Gesbit, siendo el Widgets de enlaces rápidos el único (de entrada) que no puede quitarse. Estoy pensando incluso que sería bien un "printer" para plugins de forma que pudieran añadir más enlaces rápidos a este Widget en concreto. Y, como ya sabes, cualquier plugin puede añadir ahora otros Widgets en el escritorio de Gesbit. Ahora bien, entonces, ¿qué sentido tenía mostrar de entrada los Widgets con los últimos comentarios, últimas entradas y "algunos números"? ¿Son realmente útiles? ¿Para justificar las 13 consultas SQL que tenían que llevarse a cabo?

La mayoría de usuarios no lo entenderán: al fin y al cabo Gesbit no mostraba ninguna "ralentización" por estas 13 consultas, y a más a más el escritorio no es una página que vea todo el mundo, sólo el administrador y otros autores de una bitácora, de modo que tampoco es que esté cargándose "todo el rato". La mayoría de usuarios no entenderá (o sí) que haya optado por quitar del medio los Widgets mencionados, de manera que ahora el escritorio de Gesbit, de entrada, parece casi un solar... sólo con el Widgets "Enlaces rápidos" disponible, necesitándose únicamente 6 consultas SQL para su conformación: recuérdese que el Widgets "enlaces rápidos" necesita algunas consultas.

En efecto, ahora se parte de un escritorio que precisa de 6 consultas SQL, y el usuario ya tendrá tiempo de añadir los Widgets que mejor le parezcan. Por ejemplo, he trabajado sobre uno a modo de prueba, que, no sé si llegaré a terminar, y que permite guardar un determinado "texto" dentro de un Widget. Este texto puede ser actualizado, de modo que se guarda en la base de datos, y se recupera a la entrada en el escritorio de Gesbit, únicamente. Pues bien, estoy hablando de una consulta SQL, y sólo este Widget ya me parece más útil que todos los que he quitado del medio del escritorio de Gesbit. Y una más seis son siete, o sea que dejaríamos el escritorio con 7 consultas SQL.

En definitiva, los Widgets (ahora Widgets, antes simplemente "enlaces") que he quitado del medio no justificaban de entrada el número de consultas. Si alguien desarrolla un Widget que muestre algunas estadísticas de la bitácora, y algún usuario quiere instalarlo, será ya cuestión de cada uno de ellos. Pero, de entrada, Gesbit ofrece un escritorio "limpio", que no necesita apenas consultas SQL, y, que, sin embargo, ya ofrece la funcionalidad de los "enlaces rápidos". A esto añádase que habrá Widgets que puedan añadirse sin que impliquen más consultas SQL, porque no las necesiten. En definitiva, que, aunque creo que en este tema estoy solo, sonrío con la satisfación de haber hecho algo bien, en mi opinión. No sé a ti qué te parecerá. :)

Esto último me ha llamado la atención, pero, en cualquier caso, he querido atajar el asunto, como, por otro lado, tenía pensado hacer desde hace ya tiempo. En efecto, se ha tratado de hacer ciertos cambios en la clase "I18n", de modo que ahora no establece en "cookie" alguna el lenguaje utilizado en la bitácora, y, todavía más, no recoge el lenguaje de dicha "cookie", centrándose nomás en la utilización de la constante de configuración correspondiente. Así pues la clase mantiene un método público "GetLanguage", puesto que además se utiliza en varios lugares de Gesbit (y no sobra en la clase), pero, este método retorna el valor de la constante de configuración, o el lenguaje "por defecto" en Gesbit si la constante no contuviera valor alguno.

Esto de guardar el lenguaje utilizado en una "cookie" viene de muy lejos en Gesbit, de muy atrás, de algún proyecto cuyo código sin duda aproveché en Gesbit. La consecuencia de esto es que un usuario podía cambiar el lenguaje de una bitácora, cambiando el valor de la "cookie" correspondiente, más aún, un plugin, por ejemplo, podría hacerlo también. Sin embargo, hay que pararse a pensar sobre esto, y pensar en la utilidad real de permitir algo como esto. Lo que realmente se cambia cuando se cambia el lenguaje en Gesbit es la interfaz del panel de administración, son las cadenas utilizadas en los temas, pero, evidentemente, no el contenido de una bitácora determinada. De modo que, ¿tiene sentido cambiar el lenguaje?

Casi desde el principio ví una especie de sentido, al menos dejarlo como algo "opcional", es decir, al fin y al cabo, qué problema hay con guardar una "cookie", pero, por otro lado, quizá el autor de la bitácora no quiera que nadie pueda cambiar el lenguaje (ni siquiera del tema o el panel de administración) por medio de una "cookie", y parece razonable que si él establece un determinado lenguaje, sea este lenguaje el que cuente en todo caso. Además, como he dicho al principio, dándome cuenta de que, por ejemplo, para el panel de administración se estaba actualizando la "cookie" del lenguaje en dos ocasiones, he terminado por pensar que, aunque inapreciable, algunos recursos se estaban consumiendo "para nada".

Como además era algo que quería hacer desde hace un tiempo... la consecuencia estaba clara: hacer los cambios necesarios para que no se guardara más ninguna "cookie" relacionada con el lenguaje usado en una bitácora. Son pequeñas cosillas, estas, pero, que, no sé porqué me apetece comentar también por aquí. ;)

Pues bien, eso se acabó, puesto que he hecho los cambios necesarios en el plugin Easy Widgets para jQuery, de modo que ahora los Widgets también recuerdan la posición en que se encuentran en una determinada columna, además de en qué columna se deben situar, claro está. Obviamente, estaba equivocado si alguna vez pensé "esto no se puede hacer, o es harto complicado", puesto que ha resultado ser todo lo contrario. ¡Había asumido que no podía hacerse!

Bueno. Sea como sea ya está hecho, y resulta curioso, puesto que ahora puedes situar los Widgets de marras donde te plazca, y estos se mostrarán en su posición correcta, y no en otra, aunque en la misma columna, que era algo que desconcertaba un poco. Únicamente en Opera se nota un poco que los Widgets primero se imprimen y luego se "reordenan", en el resto de navegadores en que he probado esto no se nota en absoluto. Por lo demás, tampoco es que sea algo que me preocupe, quiero decir, que se ve "algo" en Opera, pero, también se ve el resultado de ese algo. :D

Efectivamente, el asunto está planteado de forma que "todo queda en casa", me estoy refiriendo a la configuración de los Widgets, puesto que las posiciones de estos, además de otros posibles "estados" de los mismos, se guardan en el navegador del usuario en sendas "cookies". Esto puede tener y de hecho tiene sus ventajas y desventajas. Por ahora van ganando las ventajas. De momento todo queda de forma bastante sencilla, y ha sido de absoluta ayuda el plugin Easy Widgets para jQuery, y más aún que yo mismo desarrolle este plugin, pues he podido ir trasteando con el plugin y con una implementación suya: en los Widgets de Gesbit.

Esto de los Widgets en el escritorio de Gesbit me lo he tomado desde un principio como una forma de dar otro aire al aspecto del escritorio. Creo que esto se ha conseguido, y que los Widgets famosos quedan bastante bien. Además, es posible que surga algún plugin, además del que presento en esta entrada, que logre aportar cierta funcionalidad y pueda resultar útil. Sea como sea, ha sido divertido, han sido unos días muy entretenidos. Para terminar me gustaría decir que he podido probar el invento en el navegador Konqueror, algo que me preocupaba, pues todo en Gesbit funciona también en este navegador (bueno, todo, todo, no, el editor TinyMCE no funciona en Konqueror), pero, no suelo probarlo como en otros.

Y eso es todo por el momento. ¡Que tengas un buen día! ¡O una buena noche! :)

Actualización: He instalado el plugin en la bitácora de demostración, por si quieres echar un vistazo.

Lo que me ha costado un Widget, concretamente, un plugin que he llevado a cabo a modo de ejemplo (luego lo verás), ha sido el problema de la "desinstalación" de dicho Widget. Resulta que el plugin jQuery Easy Widgets puede guardar las posiciones y ciertos "estados" de los Widgets en varias "cookies". Así, cuando se añade un nuevo Widget a través de un plugin, Easy Widgets le tiene en cuenta, como no podía ser de otro modo, y guarda también sus "opciones" en las "cookies" correspondientes. Ahora bien, ¿qué pasa cuando se desinstala el Widget de marras? ¿Y qué pasa si no se desinstala (no se "desactiva") sino que se borra a lo bruto?

No era un asunto baladí, porque, era posible que se fueran acumulando opciones de Widgets en las "cookies" que, realmente, no tenían ningún sentido luego de que un Widget ya no se encontrara disponible. Así que he tomado varios caminos, esto ha sido lo que me ha costado un Widget de verdad, ¡llegando a escribir cierta solución primero en PHP y luego en Javascript, a partir de la primera! Y al cabo me he quedado con esta segunda, y no implementada en Gesbit, sino como una opción más en el plugin Easy Widgets: la opción de "limpiar" las "cookies" de modo que no queden "residuos" de Widgets inexistentes.

Me da un poco de miedo, porque, la solución en PHP (que era la misma exactamente) es algo más rápida que en Javascript. Sin embargo, el plugin Easy Widgets que llevo a cabo, opcionalmente, permite el uso de "cookies" para almacenar información, y, puesto que esto es así, tal vez es el más indicado para llevar a cabo la limpieza correspondiente, como el principal interesado en que las "cookies" contengan información válida, y porque además es este plugin quien trabaja directamente con las cookies, y no Gesbit, que, de momento, delega completamente esta tarea en el plugin para jQuery que estoy desarrollando.

Dicho esto, ¡el asunto parece que funciona! ¿Quieres ver el plugin "GbSearchBlog" que me he "inventado" a modo de ejemplo de Widgets para el escritorio de Gesbit? Helo aquí, todo se resume en un método:

  public function ActionCallback($actionID, $args){
    if($actionID == GBPLUGINS_ACTION_DASHBOARD_WIDGETS){
      $widget = new GbWidget(
        GBBLOGSEARCH_ID,
        GBBLOGSEARCH_COLUMN
      );
      $widget->SetContent(sprintf(
       GBBLOGSEARCH_CONTENT, $this->r('Search')));
      $widget->SetTitle($this->r('Blog search'));
      $widget->SetOptions(GBBLOGSEARCH_OPTIONS);
      return $widget;
    }
    return null;
  }

Como ves, el plugin espera la acción correspondiente, y, cuando se encuentra con ella, crea un nuevo objeto de la clase "GbWidget" que se limita a retornar a Gesbit. Ahí donde lo ves, sin dejar de ser simple, cumple cierto cometido, como es permitir realizar búsquedas en la bitácora, directamente, desde el panel de administración. No es un prodigio de funcionalidad, pero, creo que puede dar una idea. ¿No te parece? Gesbit espera de la acción en cuestión espera uno o varios Widgets, que serán añadidos al escritorio de gestor de bitácoras.

Gesbit no envía (de momento) ningún argumento. El plugin puede determinar el título del Widget, sus opciones (cualquiera o todas estas: "collapsable", "collapse", "editable", "movable", "removable", "confirmClose"), exactamente las que espera el plugin jQuery Easy Widgets, digo, el plugin también determina el contenido del Widget (texto plano o HTML), un identificador (obligatorio) y el número de columna donde se alojará el Widget "de entrada". Está por ver qué ocurre con Widgets más complejos, pero, al menos estos sencillos "funcionan" muy bien. Aunque, por otro lado, tal vez debería dejar de pensar mal, pues a veces no se acierta.

Como curiosidad, cuando Gesbit añade los Widgets al escritorio, en uno de ellos, el de los "enlaces rápidos", se encuentra una especie de formulario de edición, que, precisamente, permite mostrar u ocultar los Widgets a voluntad. Con los Widgets de los plugins se hace exactamente lo mismo, contando también con esta opción. Si bien es cierto que esto me deja todavía un poco preocupado, porque, se consigue imprimiendo los Widgets de todas formas, encargándose de ocultarlos el plugin jQuery Easy Widgets. Esto quiere decir que un Widget que haga una consulta SQL, por ejemplo, la hará de todas formas, se muestre o no.

Esto podría evitarse acaso no imprimiendo el Widget "oculto". De hecho es perfectamente posible, desde el punto y hora en que Gesbit tiene acceso a las "cookies" correspondientes y por tanto sabe qué Widget está ocultado en un momento dado. Pero, entonces la implementación llevada a cabo en este sentido se vendría abajo. Habría que buscar una forma de que desde los "enlaces" rápidos pudieran "mostrar" widgets que en principio no se han impreso. Es factible, creo, mediante HTTP en segundo plano, el amigo AJAX, pero, de momento no me lo he planteado. ¡Si es que no lo estoy haciendo ahora mismo!

Pero, creo que voy a dejarlo por hoy. De hecho, pensaba publicar estos últimos cambios hoy mismo, y el plugin "Widget" que he llevado a cabo a modo de ejemplo, pero, creo que voy a esperar a mañana, si es que consigo descansar, para sopesar un poco todo este asunto, sobre todo esto último que he mencionado. ¡Faltaría ahora que después de que me costase un Widget el trabajo de hoy este no sirviera para nada! Menos mal que al menos quedará en el plugin Easy Widgets, pues todo indica que las cosas se pueden hacer de muchas formas, al menos de las dos apuntadas, y así dependerá de lo que más nos interese hacerlo de una forma u otra. Y ya no digo más, que, luego todo se sabe. :)