Script para teclear la contraseña en Bankia

Tengo algunas cuentas en Bankia. A la hora de identificarme en la web para operar por Internet pide, como suele ser habitual, un usuario y una contraseña: login_bankia El problema es que, a la hora de introducir la contraseña, no permite teclear los dígitos de la misma. Para mayor seguridad han creado un pequeño teclado virtual que aparece al acceder al campo de la clave y sobre el que hay que pinchar para marcar la misma. También se puede teclear directamente pero cambian los dígitos por letras de forma aleatoria. Por ejemplo, en este caso para marcar el “1” habría que pulsar la “U”, para marcar el “5” la “B”, etc: teclado_virtual_bankia A mi esto me resulta incómodo, así que desde hace tiempo tenía ganas de programar un script greasemonkey para poder saltarme la restricción del teclado virtual y escribir los números directamente. Me daba un poco de pereza porque el código javascript que utiliza la web es Prototype en vez de JQuery que es al que estoy más habituado, pero ayer por fin me animé y me puse con ello. La idea era insertar un manejador de eventos en el campo de la clave para que al pulsar una tecla la sustituyese por el código de tecla del número correspondiente. Para eso, lo primero era obtener el campo correspondiente a la clave. Esto no es tan sencillo ya que el ID del campo de la clave es diferente en cada carga de la página, así que decidí echar un vistazo al código para ver si encontraba una forma sencilla y sobre todo robusta de hacerlo. Lo primero fue obtener y desminifizar el código. Lo que necesitaba estaba en core.js. Buscando un poco encontré la clase OI.Security.Keyboard que es donde se maneja casi todo lo referente al teclado virtual. La clase tiene una función que es la encargada de buscar el campo clave, junto con otros datos:
// Esta función se llama en el onload de la página.
OI.Security.Keyboard.registerKeyboards = function () {
    var a = OI.Security.Keyboard.prefijoInputCheck;

    $$("label.forClave").each(function (c) {
	// Esto lo que hace es buscar el campo de texto donde se introduce la clave
	// Busca las etiquetas con clase "forClave" y saca el id del campo del atributo "for"
        if (c.attributes["for"] && $(c.attributes["for"])) {
            // ¿"d" es una funcion de validación?
            var d = OI.Security.Keyboard.buscaIdCampo(c, a);
            var b = new OI.Security.Keyboard(c.attributes["for"].value, d);
            OI.Security.Keyboard.postRegisterKeyboard(b, c)
        }
    })
};
Con esto pude averiguar que el campo de la contraseña se puede encontrar buscando en el <label> con estilo forClave, y que el id se puede encontrar en el atributo for de dicho campo. La función buscaIdCampo en principio no me interesaba así que no investigué más sobre ella: parece que obtiene el nombre de una función de validación que está codificada como un estilo css aplicado al label anterior. Con esto ya pude escribir lo primero que necesitaba, una función para obtener el campo de la contraseña:
function getPasswordField(){
    var campo;
    $$("label.forClave").each(
        function (c) {
            if (c.attributes["for"] && $(c.attributes["for"])) {
                campo = $(c.attributes["for"].value)
            }
        })
    return campo;
}
Lo siguiente era encontrar la forma de encontrar a qué número pertenecía cada letra. Podría haberlo hecho examinando el DOM de la página para encontrar los elementos del teclado virtual, pero la clase OI.Security.Keyboard me lo puso más fácil todavía: en su inicialización crea también un objeto, keyboardData, que contiene la relación entre letras y números. Es más, ese objeto tiene dos funciones, valueOfLetter y valueOfNumber, que permiten hacer esa traslación directamente. Los objetos manejadores del teclado virtual se almacenan en el array OI.Security.Keyboard.keyboards (por lo que he visto en el código, pueden haber varios teclados seguros en la página de forma simultánea). El único truco fue buscar el objeto OI.Security.keyBoard en cada pulsación de teclado ya que cuando se ejecuta el script Greasemonkey todavía no está disponible (seguro que hay alguna forma más elegante de solucionar esto pero no me dediqué a investigarlo) También tuve que ver qué pasaba al pulsar una de las letras del teclado virtual, para reproducirlo en el código. Los manejadores de eventos se instalan en la función bindBehaviours de la clase. Los eventos que me interesaban llamaban a una función que a su vez terminaba llamando a la función addLetter. Esta última añade la letra correspondiente y llamaba también a la función chequeaValor(), así que esto es lo que tuve que incluir en el manejador. La última pieza que faltaba era detectar la pulsación de un número. Es posible que ya exista una función que lo haga pero perdía más tiempo buscándola que haciéndolo yo, así que programé una directamente: numberFromKeycode. Con todo esto, pude crear una primera versión del código que, instalado en el manejador del campo clave, producía los resultados esperados:
// Event handler. This function does the work.
function translateNumbers(e){
    var number = numberFromKeycode(e.keyCode);
    if (number == -1) return;

    // We must search these objects here because, if we
    // do it earlier, they are not avaliable
    var security = OI.Security.Keyboard.keyboards[0];
        // Security keyboard object
    var keyboard = security.keyboardData;
        // Virtual keyboard data
        
    passwordField.value += keyboard.valueOfNumber(number);
    security.chequeaValor();
}

// Y la instalación del manejador:
var passwordField = getPasswordField(); //Esta es la función comentada más arriba
// Add event handler to password field
Event.observe(passwordField, "keyup", translateNumbers);
Tras cargar la página de Bankia… voilà!: el teclado de login se comportaba como yo quería, admitiendo los números, y conseguí entrar por primera vez sin tener que pulsar en el dichoso teclado. Estaba tan contento con el código… hasta que se me ocurrió hacer una operación de verdad, donde la página te pide una firma digital con el mismo sistema que el del login. Ahí, el script falló y tuve que volver a poner los números “a mano”. Tras un poco de investigación descubrí que el problema es que el teclado virtual se creaba de forma dinámica, así que cuando se ejecutaba mi script (en el load de la página) no encontraba el campo clave y por tanto no instalaba el manejador. La forma más rápida de solucionar esto (que no la más elegante) fue instalar otro manejador de eventos, esta vez en la página, para que cada vez que teclease un número mirase a ver si se había creado un campo password y le instalase el manejador. Esta solución es un poco bestia pero en realida no suelo teclear muchos números en la página de Bankia así que la sobrecarga no sería excesiva:
// Search for password field every time a number is pressed.
// It could have been created dinamically, therefore it wouldn't had been installed when
// this script was loaded
function findDynamicallyCreatedPasswordField(e) {
    var number = numberFromKeycode(e.keyCode);
    if (number == -1) return;
    
    if(!passwordField) {
        // Do we have a password field now?
        passwordField = getPasswordField();
        if(!passwordField) return;
        
        // Remove document keyboard handler, it is not necessary anymore
        Event.stopObserving(document, "keyup", findDynamicallyCreatedPasswordField)
        
        // Install password field keyboard handler        
        Event.observe(passwordField, "keyup", translateNumbers);
        // Relaunch this event, or this first number would be lost
        translateNumbers(e)
    }
}

// Y la instalación del manejador:

// If password field already exists...
if(passwordField) {
    // Add event handler to password field
    Event.observe(passwordField, "keyup", translateNumbers);
} else {
    // Add a document handler to search a password field every number pressed
    Event.observe(document, "keyup", findDynamicallyCreatedPasswordField);
}
Con esto último conseguí que todo funcionara bien: ya nunca más tendré que pulsar con el ratón las letras del tecladito de las narices. Prueba superada. Tenéis el código publicado como un script de greasemonkey en userscripts. Este código es peligroso, así que antes de publicarlo le añadí una pequeña “protección” para asegurarme de que quien se lo instale sepa lo que está haciendo: no me gustaría que alguien con el ordenador lleno de troyanos se lo instalase y le pudiesen dejar pelado con un keylogger. Si habéis llegado hasta aquí seguro que no tenéis problema para editar el código y hacer lo que corresponda. Espero que hayáis disfrutado con este pequeño hackeo para hacer la vida un poco más fácil.

Script para descarga de vídeos de Coursera

Estoy viendo los vídeos de un curso de Coursera sobre computación cuántica. No voy a hacer el curso “en serio”, sólo quiero tener unas nociones básicas sobre la materia, así que estoy aprovechando tiempos muertos para ver los vídeos que previamente me he descargado en el móvil. Los cursos no tienen demasiados vídeos, pero aún así he creado un script para Greasemonkey que me facilita la vida a  la hora de descargarlos. El script crea un botón en la parte superior de la página de vídeos del curso. Al pulsarlo, se abre un nuevo tab en el navegador con un script unix que descarga todos los vídeos y los subtítulos al disco duro. Podéis descargarlo aquí: Download Coursera Videos También estoy con un curso de criptografía en Udacity, pero para bajar los vídeos y los subtítulos ya exise la extensión udacity-dl para Chrome que facilita lo suficientemente la faena como para que no me plantee desarrollar un script similar. Espero que estas dos aplicaciones os ayuden si estáis haciendo uno de estos cursos y queréis descargarlos para trabajar sin conexión a Internet. Actualización (2012-10-02): Con la nueva versión han modificado la forma de carga de los vídeos y el script ya no funciona. No tengo tiempo de mantenerlo actualizado, pero he encontrado este otro script en python que hace la misma función. Esperemos que dure: https://github.com/jplehmann/coursera

Democracia, tecnología y control

Mañana viernes 4 de Mayo de 2012 daré una charla dentro del “I Congrés de Sociologia i Ciències Polítiques de València”, titulada “Democracia, tecnología y control”. Será en el salón de grados de la facultad de Ciencias Sociales. Aquí está el horario de las ponencias. En la charla utilizaré una presentación sencilla. He creado una versión ampliada con Prezi que supongo que resultará de más utilidad. Aquí la tenéis. Es mi primera presentación utilizando esa aplicación y no he tenido demasiado tiempo para preparala, así que ser indulgentes. Cuando tenga el video disponible intentaré que esté disponible a través de esta misma entrada.

I Congrés de Sociologia i Ciències Polítiques de València

Un vistazo a iptables

Las políticas que hemos definido en el post anterior se tienen que llevar a cabo mediante iptables. No voy a entrar en detalle sobre su funcionamiento; para los interesados recomiendo el manual de iptables y el manual de filtrado de paquetes de Joan Fuster (Monzó). Dado que tenía montado un router con varios servicios en casa, ya conocía iptables y había trabajado con ella. Sin embargo, al intentar ampliar el número de redes, me he dado cuenta de que mis conocimientos eran demasiado superficiales, y que estaba dedicándome más al ensayo y al error que a una aproximación razonada del problema (por decirlo claro: que había estado varias tardes probando sin llegar a ningún sitio, y andaba bastante perdido).  Esto me llevó a plantearme el funcionamiento de iptables, ya que no sabía a ciencia cierta por dónde pasaban los paquetes, y dónde tenía que “meter mano” para conseguir lo que andaba buscando. Como se ha dicho en mil sitios, iptables tiene tres tablas: FILTER, para el filtrado de paquetes; MANGLE, para realizar marcaje en los paquetes de comunicaciones, y NAT, para realizar… pues eso, NAT.Cada una de estas tablas tiene unas cadenas predefinidas. Una cadena es algo que se ejecuta cuando el paquete llega a un sitio determinado. Se llama cadena porque puede contener varias reglas, que se ejecutarán una después de otra, y que son las que podemos definir. ¿Cuándo se ejecutan cada una de esas cadenas? Eso es lo que no tenía claro, de manera que lo primero fue buscar un esquema de funcionamiento que relacionase las tres tablas y cada una de sus cadenas. Lo encontré en el manual de iptables, y lo reproduzco aquí en un formato un poco más aseado que de donde lo copié: En verde he marcado la tabla FILTER, en amarillo la tabla NAT y en azul la tabla MANGLE. El texto en las elipses es el nombre de la cadena que se ejecuta. De este modo, podemos ver que se ejecuta antes la cadena FORWARD de la tabla mangle que la cadena FORWARD de la tabla filter. Este orden es importante a la hora de diseñar las reglas que utilizaremos. En iptables se pueden crear cadenas definidas por el usuario, que se lanzarían desde las cadenas predefinidas, pero es algo que no voy a utilizar y no he entrado a mirarlo en detalle. Ahora, con esta información, ya tengo más claro cómo hay que transformar las políticas de acceso en reglas de iptables. Por regla general, para las políticas de acceso utilizaremos la tabla FILTER. Para dar acceso a internet desde una sola IP utilizaremos la tabla NAT, y la tabla MANGLE va a ser útil para las políticas de QoS, con las que espero meterme algún día. En fin, sigamos.

Políticas de acceso

Una vez hecho el mapa de la red, tengo que decidir qué quiero. Este es un mapa simplificado de lo que rodea al router: Y esto es lo que quiero que pase en la red:
  • No se admitirán conexiones entrantes al router, excepto:
    • A algunos puertos determinados, desde Internet
    • Desde casa se podrá acceder a cualquier puerto del router
  • No se permitirá tráfico desde redlibre a la red de casa, ni al router
  • Desde casa y desde redlibre se tendrá acceso a internet
Supongo que sobre la marcha tendré que corregir alguna cosa, y hay algunos detalles que no he incluido por simplificar. Ahora, con iptables, tengo que poner en marcha esas políticas.

Red Valenciawireless

Tengo pendiente desde hace un tiempo montar un nodo de Valenciawireless para dar servicio a la zona donde vivo. Hice una prueba rápida, dio problemas, y hasta ahora no me había podido poner en serio con el asunto. Para montar el nodo necesito dos cosas: configurar la red, y configurar políticas de QoS (calidad de servicio) para priorizar el ancho de banda de mi tráfico particular; no quiero que porque haya mucha gente conectada al nodo empeore la conexión a internet de mi ordenador. De QoS hablaré en otro post… cuando tenga las cosas más claras. Ahora estoy en el proceso de configurar la red. Lo primero ha sido hacer un esquema de cómo tengo las conexiones en casa, por aclararme las ideas. Ha resultado ser algo así:
Esquema de red de casa
Las máquinas que aparecen en el gráfico son estas:
  • mosca: el portatil que hace de servidor, router, firewall y emule-tutiplén.
  • mantra: mi portatil
  • brondo: mi ordenador de sobremesa (que algún día ira a la basura, por lo poco que lo utilizo)
  • petuneta: el ordenador de mi novia
La duda que tengo es si funcionará bien el esquema que da a servicio a RedLibre (en la parte superior derecha del gráfico) El router no traslada tráfico a ningún sitio, podréis ver que no está conectado a nada. Su función es proporcionar conexión de tipo infraestructura a los clientes de Redlibre, y hacer de servidor dhcp, diciendole a los clientes que la puerta de enlace por defecto es la tarjeta wifi del servidor que tengo en casa. Hasta donde sé eso debería funcionar, pero me da mal fario. Intentaré echarle un vistazo la semana que viene a ver si consigo tener conexión y salida a internet desde la red de los invitados. Cuando tenga eso listo, tendré que conectar el sistema a Redlibre. Y después, preparar QoS que creo que va a ser lo más complicado: me va a tocar parchear el núcleo, y eso es algo nuevo para mi. A ver si consigo tener todo listo para primavera, que en el parque de debajo de casa se empieza a estar bien.

SSH más seguro

Al revisar el correo local del servidor que tengo instalado en casa (Ubuntu 8.04 server, migrado de la siete y pico) me he dado cuenta de que tenía un puñado de correos de crontab avisandome de que /var/log/messages había desaparecido. Puesto a revisarlo me he dado cuenta de que además de ese fichero, existen otros bastante importantes como auth.log. Revisandolos, he descubierto que hay algunos cuantos listos intentando acceder a mi servidor ssh, probando con usuarios y contraseñas al azar. No creo que hubiese pasado nada (no tengo un password muy estándar) pero más vale prevenir: tras bucear un poco, he encontrado la utilidad denyhosts. Esta aplicación revisa los logs y bloquea los ordenadores que acceden de forma errónea, tras un número determinado de intentos. Estaba dispuesto a pegarme un poco con algún script de shell, ya que había visto hace un tiempo una solución hecha “a mano” para lo mismo, así que me ha sorprendido gratamente el encontrarla, ya que hacer justo lo que quería. Instalarla no puede ser más fácil, sólo hay que seguir dos pasos:
  1. Instalar denyhosts (apt-get denyhosts)
  2. Editar /etc/ denyhosts.conf . Es muy sencillo y autoexplicativo, y en principio no hay que tocar nada. Yo lo he hecho porque me conozco, así que he rebajado un poco la segurida por si me empeño en meter la pata a la hora de conectarme.
Al rato, ya tenía mi primer informe de denyhost donde me indicaba los atacantes bloqueados de la noche anterior. Parece que la cosa va bastante bien, a ver si así me ahorro algún susto:
From: DenyHosts <nobody@localhost>
To: root@localhost
Subject: DenyHosts Report
Added the following hosts to /etc/hosts.deny:
222.215.119.33 (unknown)
87.238.89.132 (132.net-2.pl-medusa.net)
219.159.186.81 (unknown)
125.46.36.89 (hn.kd.ny.adsl)
117.120.8.46 (unknown)
60.248.36.227 (mail.liveabc.com)

Gestores de contenidos

Hace un par de días llamé a un amigo y lo encontré trabajando con el ordenador intentando montar una web. No es informático: trabaja de guía turístico y quería montar una página para ofrecer sus servicios. Había contratado alojamiento, un dominio, y estaba empezando a editar un index.html para la página inicial. También había “adquirido” una copia de Dreamweaver y pensaba montar su sitio web a mano, con esa herramienta.

Creo que le llamé justo a tiempo, porque montar una web así hoy en día es una locura. Merece la pena si quieres algo muy especial y tienes dinero para que te lo haga una empresa especializada, pero para un negocio personal el trabajo es tremendo, el mantenimiento va a ser horrible, y las funcionalidades mínimas. Le recomendé que instalase un CMS y se dedicase a cambiar el diseño y a generar contenido. Como no tiene ni idea de lo que es un CMS, quedé en que se lo explicaría en un correo y le mandaría algunos ejemplos de lo que se podía hacer. Como ya tengo página personal (montada también sobre un CMS) voy a aprovechar para escribirlo aquí y así lo tengo listo para cuando algún otro amigo decida meterse en estos líos.

Qué es un gestor de contenidos

Lo primero es contar lo que es un gestor de contenidos. En la wikipedia hay algo de información, que yo resumiría en lo siguiente: al final, en Internet todo el mundo quiere hacer lo mismo: montar una tienda online, crear un blog, publicar un periódico… Lo que sucedía al principio es que cada uno preparaba su aplicación específica. Si el tendero del barrio quería tener una página web, contrataba a una empresa que se la diseñaba y programaba (y que le costaba un dineral). Si alguien quería una página personal, la editaba a mano e iba incluyendo cosas. El problema de esto es que se repetía mucho trabajo, ya que, aunque duela reconocerlo, todas las tiendas en internet son parecidas y todas las páginas personales, blogs, etcétera tienen la misma funcionalidad.

Como esto era así, en un momento dado alguien tuvo una idea genial: preparar un programa que se pudiese reutilizar para diferentes páginas web. Permitía configurarlo (cambiar menús, añadir artículos, ocultar/mostrar diferentes secciones…) y cambiar el diseño (colores, tipos de letra, etc…). Si alguien quería crear una página web, no tenía que programar nada: sólo instalar el gestor de contenidos y dedicarse a editar los contenidos (añadir artículos e información) y a cambiar el diseño para dejarlo a su gusto. Utilizando un mismo programa, se podían crear dos webs totalmente diferentes y personalizadas. Por ejemplo,  esta web y esta otra utilizan el mismo programa base.

Esto sería, simplificándolo un poco, un gestor de contenidos o CMS.

Utilizar un gestor de contenidos a la hora de montar una página web en vez de programarla desde cero nos da las siguientes ventajas:

  • Tiene mucha funcionalidad incluida desde el principio, sin tener que programar nada.
  • Se administra desde Internet: no hace falta ningún programa especial (ni comprarlo, ni instalarlo) y lo puedes hacer desde cualquier ordenador con conexión.
  • Es muy sencillo añadir y modificar contenido sin romper nada.
  • Es estándar, por lo que puedes encontrar mucha información en Internet (foros, tutoriales) y en un momento dado, es más sencillo encontrar a alguien que te eche una mano
  • Se puede configurar para que el diseño sea propio (menús, secciones, etc.) . Además, mantiene la coherencia de diseño en todo el sitio web.
  • Son ampliables. Si necesitas una funcionalidad que no viene “de serie”, se puede añadir mediante módulos o plugins. Hoy en día hay plugins para todo en los principales CMS: desde foros, a tiendas virtuales o galerías de fotos y vídeo.

Lo malo… bueno, lo malo que se me ocurre es lo siguiente:

  • Son difíciles de personalizar más allá de los límites que proporciona el gestor de contenidos: por ejemplo, si un gestor de contenidos no permite configurar la posición de los menús, y queremos que en nuestra página. Si nos emperramos en hacer algo para lo que el gestor de contenidos no está preparado, podemos volvernos locos.
  • Al ser aplicaciones estándar, están más expuestas a fallos de seguridad: si alguien descubre un fallo en la aplicación, lo podrá usar en muchos sitios web.  Aunque también es verdad que esas aplicaciones suelen ser más seguras porque se depuran mucho más los errores.

Para montar la página de un pequeño negocio, o una página personal, las ventajas de un CMS superan con creces a los inconvenientes.

Qué gestor de contenidos utilizar

Lo primero, hay que saber qué gestores de contenidos hay.

Para sitios web de propósito general (sería el caso de mi amigo):

Para blogs y páginas de publicaciones:

Los motivos para elegir uno u otro pueden ser muy técnicos (rendimiento, extensiones disponibles, posibilidad de gestionar varios sitios web, etcétera). No he hecho un análisis a fondo de los diferentes gestores, pero he probado Joomla y la verdad es que me siento muy cómodo con él. He oído comentarios sobre que Drupal está mejor hecho “por dentro” (pero también que era mucho más complicado de utilizar al principio) y que TextPattern es mucho más elegante y limpio en el código que genera. A pesar de eso, mi recomendación personal para mi amigo sería utilizar Joomla: es razonablemente potente y sencillo de utilizar, y para lo que el quiere, tiene de sobra. OJO: la versión 1.0 da problemas en alojamientos compartidos, es importante utilizar la versión 1.5

Cómo utilizar un gestor de contenidos

Es lo más sencillo del mundo: instalar el gestor de contenidos, personalizarlo y añadir contenido a la web.

Para instalar un gestor de contenidos necesitamos que el proveedor de alojamiento nos proporcione dos cosas: soporte para PHP y soporte para base de datos; estas dos cosas las ofrecen prácticamente todas las empresas. La instalación suele consistir en dejar caer unos ficheros en el servidor, preparar una base de datos (que suele ser mySQL) y acceder al sitio web donde se muestra una pantalla de configuración que nos pide los datos adicionales y nos va guiando hasta que tenemos todo listo. Este proceso no suele costar más de diez minutos, aunque si es la primera vez, puede que necesites dos o tres horas para dejarlo todo en su sitio.

Personalizarlo es algo más complicado, ya que en este paso es donde vamos a definir el aspecto final que tendrá la página web. Lo bueno es que podremos dedicarle el esfuerzo que queramos. Recién instalado el gestor de contenidos ya tendremos una página web funcional. A partir de ahí, podemos descargar e instalar sin mucho esfuerzo alguna plantilla que mejorará bastante el aspecto (aquí, por ejemplo, hay un buen directorio de plantillas joomla).  Luego, se puede modificar esa plantilla o crear una nueva para que nuestra página se muestre como queramos.

Por último, lo que más faena tiene, es dotar a la web de contenido: escribir artículos, poner cosas interestantes, hacerla atractiva para la gente que queramos que la visite. Pero eso es algo que tenemos que hacer de todas formas, usemos el gestor de contenidos o no.

Todo esto, que suena muy complicado, no lo es tanto. Lo mejor es probar a instalarlo, jugar un poco con el gestor y acostumbrarse al manejo. Joomla Spanish es un buen sitio para empezar.También es buena idea leer algún tutorial como este. Una forma sencilla de probar joomla es instalarlo en el propio ordenador, pero quizá nos complique más la vida (hay que instalar un servidor web, un servidor de bases de datos, php…) así que creo que es más sencillo probar directamente en el servidor.

A partir de aquí, como casi todo lo de informática, hay que empezar a probar, jugar con el gestor de contenidos y empezar a experimentar y a equivocarse. Siempre vamos a perder menos tiempo que haciendo la web desde cero.

OpenId

A estas alturas no voy a ponerme a explicar lo que es OpenId, sólo citar que:
OpenID es un sistema de identificación digital descentralizado, con el que un usuario puede identificarse en una página web a través de una URL (o un XRI en la versión actual) y puede ser verificado por cualquier servidor que soporte el protocolo.
(Aquí y aquí podéis encontrar más información) Quería disponer de un servidor OpenId propio, ya que no me gusta depender de otros servicios para gestionar mi propia identidad. Tras estudiar las opciones disponibles, al final me decanté por phpMyID. Se trata de dos scripts en PHP que se configuran con relativa facilidad: basta con dejarlos caer en el servidor, editar un par de parámetros y generar la contraseña. La parte más difícil viene si al intentar autentificarnos muestra un error “Missing expected authorization header”. Esto es debido a que PHP no puede leer las cabeceras HTTP, y para solucionarlo sólo tenemos que subir el archivo .htaccess que proporciona la distribución de phpMyID y en el que previamente habremos descomentado una de las tres opciones disponibles (yo probé con la primera). Con estos pasos tenemos un servidor OpenId monousuario funcionando en cinco minutos. Una vez configurado el script, la dirección para autentificarnos es http://nuestrositioweb/MyID.config.php. Esto queda muy feo, ya que si lo utilizamos, por ejemplo, para identificarnos a la hora de escribir un comentario en un blog,  cuando los lectores pulsen sobre nuestro avatar o nuestro nombre irán a una página bastante simple que dice “This is an OpenID server endpoint”, sin mucha más información. Para corregir esto se utiliza la delegación: en una página determinada, que es la que queremos que visiten los usuarios, se añaden dos tags html que indican dónde está realmente el servidor OpenId que nos autentifica. Los tags son <link rel=”openid.server”…/> y <link rel=”openid.delegate”…/> Podría haberlos añadido a mano, pero como utilizo WordPress en esta página, me pareció que la solución más limpia era instalar un plugin que realizase esa delegación. He utilizado OpenID Delegate WordPress Plugin, también muy sencillo de instalar (dejar caer el archivo) y de configurar (poner en los dos primeros campos que aparecen en su sección de administración la dirección del script phpMyID). Con esto he conseguido que la dirección de mi página personal me sirva para autentificarme con OpenID. Rápido, fachile e divertente. Gracias Señor Siege.

Cambio de servidor

Tras unas semanas de prueba he llegado a la conclusión de que la velocidad de subida que tengo en mi casa es insuficiente. Las veces que he accedido yo para comprobar la velocidad o hacer algún retoque en la plantilla me ha resultado exasperante, y eso que hay que tener en cuenta que no estaba conectado el emule o bittorrent (para compartir contenido sin derechos de autor, desde luego 😉 ) ni está operativo del todo el nodo de redlibre: cuando lo esté, con la VPN y algún cliente conectado, puede resultar muy incomodo acceder a mi web. Dado que quiero usar esta dirección para temas profesionales, he decidido pagar tres euros al mes y quitarme problemas. He contratado alojamiento en dhapcenter, que resulta muy barato y tiene un panel Plesk con el que se manejan los dominios con bastante facilidad. Monté en su día una web profesional, Psiconsultaonline (otro día hablaré de ella) y salvo algún que otro problemilla por ser alojamiento compartido quedé muy contento. Además, la empresa está en Paterna, cerca de donde vivo, así que puedo acercarme en persona a cantarle las cuarenta a alguien si la cosa se pone fea. Otra ventaja es que en caso de que una catástrofe natural afecte al servidor (terremoto, huracán, impacto de meteorito) no me importará: tendré cosas más importantes de las que preocuparme. El cambio ha tardado un poco porque en Agosto las cosas van muy despacio y dar de alta el dominio ha costado casi una semana, pero por fin estoy por allí. Ahora a seguir retocando, que todavía queda algún “Komentarien” y alguna “Kategorien” que clama al cielo. No sé si lo haré a las bravas o utilizaré el método bueno del gettext. Eso se queda también para otro post.