Aquí os traigo un pequeño script que he hecho para enterarme de esto. Sé que hay por ahi muchos servicios que hacen lo mismo, los he probado y todos me han parecido una chusta, publicidad, desfase en la notificación y en general nada que cumpla bien algo tan simple como esto. Por eso he acabado tirando unas líneas de código para tenerlo en mi propio servidor y hacer exáctamente lo que espero, que es muy sencillo: recibir un email cada vez que alguien deje de seguirme en Twitter. A continuación explico algunos detalles de esta mini aplicación que podéis descargar desde github.

Lo primero aclarar que obviamente no es una aplicación de uso general, por las siguientes peculiaridades:

• Aunque fácilmente modificable, hace únicamente lo que yo necesito, explicado al principio
• Está limitada a 5000 followers (por defecto el límite de la API de Twitter si no se utiliza paginación), cuando sobrepase esa cifra ya lo modificaré ;)
• Utiliza un fichero para almacenar los followers y arrays para comparar, lo cual con un número elevado de ellos no sé cómo rendirá

Al turronaco. El único requerimiento es la extensión curl de PHP, que se utiliza para llamar a las APIs de Twitter. La gestión de errores es como un martillo, si no hay curl o alguna API devuelve un error el script termina, no necesito nada más sofisticado.

La única personalización necesaria está en el fichero twitter_unfollowers.php, para los campos del email que recibiremos:

11
12
13
14
15
16
17
18

// fichero donde se guardan los followers para posteriormente compararlos con los actuales
define('FIC_GUARDADO', 'twitter_followers_{USUARIO}.db');
// poner a 0 si no quieres recibir un email con la lista de unfollowers
define('ENVIAR_EMAIL', '1');
define('EMAIL_DIRECCION', 'xxxx@yyyy.com');
define('EMAIL_ASUNTO', '[TWITTER] Te ha(n) desfollogüeado {NUM} usuario(s)');
// dirección válida en el servidor donde se ejecuta el script para que el email no se vaya al spam
define('EMAIL_REMITENTE', 'iiii@jjjj.com');

Podemos utilizar esta clase en un simple script que se pondría en el cron, como por ejemplo:

1
2
3
4
5
6
7
8
9
10
11

<?php
 
	require('twitter_unfollowers.php');
 
	$tuiter = new Twitter_unfollowers('<id_usuario_twitter>');
 
	$tuiter->check_unfollow();
 
	echo 'fin';
 
?>

Changelog

v1.0 – Desarrollo inicial
v1.1 – Eliminada la necesidad de autenticarse con OAuth para utilizar las APIs
v1.2 – Arreglados problemas de codificación y control de errores de la API

En mi caso concreto pepe.com es un dominio antiguo, y quiero que toda referencia a él acabe en el nuevo, digamos paco.com. Para ello utilizo un htaccess que hace una redirección 301 a lo bruto:

# colocado en /home/web/pepe/.htaccess
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)$ http://www.paco.com [R=301,L]

Éste es mi problema concreto, pero por ejemplo es también muy común en frameworks y CMS hacer una redirección general de todas las peticiones a un único fichero. Vamos, que aquí lo importante es la reescritura general.

Ahora lo que quiero es proteger con contraseña el acceso a mi administración, por lo que utilizo otro htaccess con el contenido estándar para ésto:

# colocado en /home/web/pepe/admin/.htaccess
AuthType Basic
AuthUserFile /home/web/pepe/admin/.htpasswd
AuthName "Acceso Administrador"
Require valid-user

Y como no podía ser de otra forma el invento no funciona. Cuando intento acceder a http://www.pepe.com/admin me redirige a http://www.paco.com, luego el primer cambio es meter una excepción para que no aplique la regla de reescritura para la URL que nos interesa. Lo podemos hacer en el htaccess principal con una condición:

# colocado en /home/web/pepe/.htaccess
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/admin/?RewriteRule ^(.*)$ http://www.paco.com [R=301,L]

O si no necesitamos de ninguna reescritura en el directorio hijo podemos directamente desactivar el engine:

# colocado en /home/web/pepe/admin/.htaccess
RewriteEngine offAuthType Basic
AuthUserFile /home/web/pepe/admin/.htpasswd
AuthName "Acceso Administrador"
Require valid-user

Cojonudo, pero sigue haciendo la redirección. Primera comida de cabeza importante: comento todas las reglas de reescritura y sigue redirigiendo ¿? resulta que Firefox cachea las redirecciones (al menos las 301), así que ya puedes darle a F5 y estar correctas las reglas, que no te enterarás si no borras la caché del navegador, eso o utilizar Explorer (no lo he probado en el resto).

Descartado el navegador, ésto sigue sin rular. Utilizando el imprescindible HttpFox y Google descubro que la autenticación básica de Apache que queremos usar manda una cabecera 401 Unauthorized, que el navegador recibe y es cuando muestra el cuadro de usuario/contraseña. Segunda comida de cabeza importante: el servidor está buscando un mensaje de error personalizado para el 401 (en una directiva ErrorDocument), que no encuentra y por tanto lanza, adicionalmente, un 404. Y resulta que, no me preguntes por qué, este último error pasa por la reescritura general y es lo que está provocando la redirección. Acojonante. La solución es definir dicho ErrorDocument en nuestro htaccess:

# colocado en /home/web/pepe/.htaccess
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/admin/?
RewriteRule ^(.*)$ http://www.paco.com [R=301,L]
ErrorDocument 401 "Acceso restringido"

¡Aparece el cuadro para meter usuario/contraseña! joder, ha costado.

Antaño, cuando perdías un PC era poco menos que una hecatombe (y una especie de catarsis cuando lo asumías): fotos, música, documentos, toneladas de películas… hoy en día Internet lo ha cambiado todo, y al menos los hardcore users (a los que siempre asocio con el iPhone, al menos con el uso intenso del iPhone al que aquí me refiero) ya guardan gran parte de esa información en la nube.

Éste es uno de los ingredientes de la tragedia. El otro es la miniaturización del hardware y el poder llevar ahora un mini ordenador en el bolsillo, dispositivos que permiten acceder a la nube desde cualquier sitio.

En definitiva: cacharro + nube + pérdida/robo = El Horror

Y para ilustrar mi pavor, una captura de la pantalla principal de mi iPhone, así que el desgraciao que lo encontrara/robara tendría acceso a:

• Contactos: tener el número de mi madre y llamarla para burlarse de lo mandril que es su hijo es todo uno.
• Calendario: ver dónde y a qué hora tendría una cita, podría venir a robarme la cartera también.
• Fotos: ni te cuento, de hecho se me están poniendo los pelos como escarpias de pensarlo, voy a borrar algunas…
• MoneyBook: app para llevar un control de gastos personales, aquí la verdad más que nada le entraría la risa…
• Remember the milk: app para el control de tareas, lo mismo, “comprar calcetines de algodón” es algo íntimo que no debe ser compartido.
• MobileRSS: lee tus propios feeds, desgraciao!
• Tiempo: que pueda consultar el tiempo que hace en Elche desde MI telefóno no es justo.
• Twitter: aquí traspasamos la delgada línea roja: redes sociales. Empezar a seguir a Enrique Dans me parece un ejemplo bastante cruel de puteo con mi cuenta…
• Facebook: no te digo ná y te lo digo tó!
• Tumblr: aquí sí que me cabrearía, mi tumblr es ahora mismo la joya de lo corona, pff…
• LinkedIn: supongo que arruinar mi carrera profesional con un “mecagontosmisjefes” es un buen puteo.
• Evernote: aquí hay un poco de todo: facturas, apuntes, contraseñas, etc… vamos, el Dorado del desgraciao.
• Dropbox: pues lo mismo, si Evernote era el Dorado, éste es el Santo Grial.
• Mensajes: y además ordenaditos por conversación, un puto lujo oche!
• Mail: acceso directo y rápido a todas mis cuentas de email, el único límite es la imaginación!

Bueno, creo que el concepto ha quedado claro. Y ésta es una página de 4 (y lo restauré hace poco…) de aplicaciones, telita!

Y sí, claro que tengo activo el bloqueo con código, pero sin saber ni papa de estas cosas, pondría la mano en el fuego a que hay alguna forma sencilla de saltarse esta protección… lo dicho, tal es el acojono que me estuve planteando pagar por una cuenta de MobileMe únicamente por el borrado a distancia, pero no, he optado por la opción gitaner: un móvil de los que darían con los cereales que no tenga ni WAP para llevar en determinadas salidas (principalmente cualquiera que implique noche). Mi iPhone es mucho iPhone.

El ejemplo por antonomasia es por supuesto el de Google Reader, pero hay muchos más: Facebook (fijaros que lo hace una vez cuando vas a mitad de página), Digg, Bing, Vimeo, Dropular….

Básicamente consiste en cargar más contenido dinámicamente conforme te acercas al final de la página, de forma que la navegación por el mismo no queda interrumpida en ningún momento. Viene a ser un sustitutivo de la paginación tradicional.

Luego comentaré los pros y contras que pienso tiene esta técnica. Antes contar cómo lo he implementado en mi tumblr, micro Usuario de Internet, algo que llevaba bastante tiempo queriendo hacer y que sin duda opino le va como anillo al dedo.

Aunque en principio tenía intención de remangarme, encontré un plugin, de-pagify, que lo implementa de forma muy flexible y aprovechando parte de la magia de jQuery. Utilizar un framework de javascript simplifica considerablemente la codificación del método, que de otra forma sería bastante más laboriosa, sobre todo el paso de procesar el contenido para pintarlo en pantalla.

En la página del plugin viene todo explicado muy claramente, sólo destacar dos cosas:

• Hay 4 formas de lanzar el evento para traerse más contenido. Se configura con el párametro trigger, y puede ser cuando se llegue a un % de altura de la página, a una altura determinada (pixels), cuando se vea un determinado elemento de la página (mi elección) o incluso dependiendo de la salida de una función propia. La flexibilidad es máxima.
• Como he comentado, utilizar jQuery ahorra mucho código, y una de las perlas que más me ha gustado es la siguiente línea:

  // Format url as "?page=1 div#wrapper div.post"
  var url = [next.attr('href'), options.container, options.filter].join(' ');

  El método de ajax load, que es con el que nos vamos a traer el contenido de la siguiente página para pintarlo dinámicamente, permite especificar la URL con selectores separados por espacios, de manera que podemos controlar qué elementos, qué HTML al fin y al cabo, queremos que se cargue en la capa que eligamos. Ésto nos ahorra de una tacada tener que hacer alguna modificación en el código de la aplicación (se van a ir pidiendo por ajax sucesivas páginas como si la navegación fuera la clásica) y tener que procesar el HTML que recibimos (se pinta tal cual porque ya viene filtrado con el contenido, lo único que he tenido que modificar de la página es un poco la maquetación).

En definitiva, y en mi opinión:

PROS

• Experiencia de usuario: no tengo la menor duda de que, para cierto tipo de webs y, sobre todo, de contenido, el eliminar la paginación supone una mejora muy significativa en la forma de navegar por el sitio, comportándose de la forma natural en la que uno esperaría moverse por él.
• Consumo: cuando desaparece el punto final (pie de página y paginación) pasa a ser un comportamiento natural el hacer scroll indefinidamente y por tanto seguir consumiendo el contenido de manera indefinida.

CONTRAS

• Experiencia de usuario: y no es una contradicción, la nueva forma de navegación puede confundir a muchos usuarios menos duchos en esto de Internet, acostumbrados a los puntos de ruptura (paginación), a saber por qué página del libro van y a una estructura de web más convencional.
• Implementación: no es tema trivial, ya no técnicamente, sino desde el punto de vista de la usabilidad. Por ejemplo está muy unido al dispositivo utilizado: con la rueda del ratón todo es maravilloso, con el teclado o arrastrando la barra de scroll ya pueden darse saltos incómodos. La norma aquí es que sea prácticamente imperceptible para el usuario lo que se está cociendo de fondo (aquí tengo que mejorar mi implementación).
• Monetización: en sitios que se ganan las habichuelas con la publicidad puede suponer un problema la ubicación de los bloques de anuncios. Un esquema típico de jumbobanner arriba, roba a la derecha y Adsense bajo el contenido queda bastante desvirtuado con esta navegación. Lo mismo con páginas vistas (solucionable con una buena semilla).

Entradas relacionadas:

1. Error en la codificación con AJAX
2. Internacionalización con Smarty

El temita de la internacionalización (i18n para los amigos) en una aplicación web puede dar para largo y tendido, yo voy a hablar aquí concretamente de la forma de guardar y utilizar las cadenas de texto del site en varios idiomas utilizando el framework de templates Smarty.

Hay muchas formas de hacerlo, se pueden encontrar varias alternativas en este post de best way to build a multi-language site with smarty, que empezó en el ¡2003! (el frenético ritmo que lleva la tecnología hace que no me crea nada que no sea de ayer…). Todas tienen sus ventajas e inconvenientes, y dado que no hay nada en el core de Smarty para ésto ni una solución popularmente aceptada como la estándar, cada uno debe analizar lo que necesita para su proyecto y tener unas preferencias subjetivas, que en mi caso son:

• Que no implique PHP: obviamente hay opciones mucho más sofisticadas, eficientes, etc… para solucionar el tema del i18n con programación (por ejemplo smarty-gettext), pero precisamente el uso de Smarty es para separar la lógica de la aplicación de la de presentación, y dado que considero que ésto es problema de front-end puro, yo quiero resolverlo únicamente con Smarty.
• Que sea sencillo y eficiente: con el tiempo me estoy conviertiendo en un talibán del código, en el sentido bueno (creo) de intentar que las cosas se hagan de la forma más clara posible (KISS power!) y que note un pinchazo en el corazón con cada ciclo de reloj que se consume en código prescindible.

Por ejemplo, hay una solución muy buena y que he utilizado en otros proyectos, SmartyML, pero es una clase más en PHP (una capa más para procesar) y viendo tanto código pienso que debe haber una forma mejor de hacerlo.

Pero vamos al turrón. Al final encontré en el foro antes mencionado la solución que me parece más sencilla y adecuada para lo que necesito. Se trata de utilizar archivos de configuración (1ª ventaja: es una funcionalidad core de Smarty, con lo que no hay que añadir más complejidad). En estos ficheros se definen variables globales para los templates y se pueden aplicar de varias formas:

// desde el PHP
$smarty->config_load('fichero.conf');
 
// desde el template
{config_load file='fichero.conf'}

Yo prefiero hacerlo desde PHP porque la gestión del idioma de la web es lógica de aplicación y hay que poner cada cosa en su sitio. El directorio donde se almacenan estos ficheros debe ser definido en el código:

$smarty = new Smarty();
$smarty->config_dir   = '/path/al/directorio/';

Crearemos un archivo por idioma, en los que tendremos todas las cadenas de texto que vamos a utilizar traducidas, por ejemplo:

# /path/al/directorio/es.conf (español)
saludo = hola!
enviar = Enviar
cancelar = Cancelar

# /path/al/directorio/en.conf (inglés)
saludo = hi!
enviar = Send
cancelar = Cancel

Utilizar estas variables en los templates es tan sencillo como usar la sintaxis {#variable#}, por ejemplo:

<strong>{#saludo#}</strong>
<input type="button" name="enviar" value="{#enviar#}" />
<input type="button" name="cancelar" value="{#cancelar#}" />

¡Y ya está! desde el PHP se puede controlar qué archivo de configuración de idioma cargar y de esta manera tener montada nuestra web multilenguaje. Unos últimos apuntes:

• Las cadenas también pueden llevar texto variable, como por ejemplo un saludo del tipo Hola Fernando, bienvenido! Ésto se puede solucionar de dos formas:

  # forma CUTRE: en el tpl
  <strong>{#saludo1#}{$nombre_usuario}{#saludo2#}</strong>
   
  # en el archivo de configuración de idioma
  saludo1 = Hola
  saludo2 = bienvenido!

  # forma CORRECTA: en el tpl
  <strong>{eval var=#saludo#}</strong>
   
  # en el archivo de configuración de idioma
  saludo = Hola {$nombre_usuario}, bienvenido!

• En lo que entiendo es una optimizacion (supongo que a nivel interno se controlará), se pueden utilizar secciones (referenciadas así [seccion]) en el archivo de configuración, de manera que si se especifica una en el config_load sólo esas variables se cargarán (la que estén fuera de una sección estarán siempre disponibles). Ésto nos puede servir para organizar las cadenas de texto por página y suponer que Smarty lo manejará mejor que el chorro completo de variables. Quedaría así:

  # cadenas globales
  saludo = Hola!
  enviar = Enviar
   
  # página de login
  [login]
  titulo = Introduce tu usuario y contraseña

  Y desde el PHP:

  $smarty->config_load('es.conf','login');
  $smarty->display('login.tpl');

• Una desventaja es que no maneja de manera nativa los plurales como otras soluciones, de forma que hay que controlarlo a manubrio, por ejemplo:

  # en el tpl
  {eval var=#subida_fotos#}{if $num_fotos > 1}s{/if}
   
  # en el archivo de configuración de idioma
  subida_fotos = Has subido {$num_fotos} foto

Entradas relacionadas:

1. Error en la codificación con AJAX
2. Scroll infinito con jQuery

La filosofía del single sign-on ha terminado imponiéndose por pura lógica de saturamiento 2.0, con los grandes jugadores vendiendo sus nuevas propuestas (OpenID lo intentó y no lo consiguió…) y los usuarios cansados de procesos de registro y contraseñas varias. Darles a éstos la oportunidad de usar sus credenciales de alguno de los servicios top para utilizar tu sitio debería ser ya a estas alturas planteado como una funcionalidad primaria de cualquier proyecto web.

Lo que viene a continuación es una guía para implementar en tu web la funcionalidad de “login externo” usando las APIs de tres de los grandes: Facebook, Yahoo y Windows Live (Google y OpenID vendrán en otro post). El proceso es similar en todos los casos, y el objetivo es acabar teniendo para utilizar en nuestro código el id único externo (la variable $id_unico en los ejemplos) que nos sirva para identificar y validar al usuario en nuestro sistema local.

Facebook

La integración más sencilla de todas ¡5 líneas de código!

La documentación para desarrolladores de Facebook es de las mejores, con muchos ejemplos prácticos y una comunidad muy activa. Vamos a hacer la implementación más sencilla, sin meternos en Facebook Connect, que será chicha para otro post. Los pasos serían los siguientes:

1. Logueado en tu cuenta de Facebook debes añadirte la aplicación para desarrolladores.
2. Creamos una nueva aplicación, y rellenamos lo básico para que funcione (el resto es para configuraciones más avanzadas)

   

3. Nos bajamos la librería cliente de PHP.
4. ¡Y a picar!

Resumiendo, tenemos una api key, otra key privada, hemos especificado una URL propia de retorno de Facebook, y tenemos su clase de PHP (nos sobraría con los ficheros facebook.php y facebookapi_php5_restlib.php). Pues el script para loguearse con Facebook sería tan sencillo como esto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
 
	// cargamos la clase que nos proporcionan
	require_once('apis_externas/facebook/class_facebook.php');
 
	// datos de la aplicación que se nos facilitan cuando la registramos en Facebook 
	$appapikey = '000000000000';
	$appsecret = '111111111111';
 
	// inicializamos el objeto de la clase
	$facebook = new Facebook($appapikey,$appsecret);
 
	// si el usuario no está logueado en Facebook le redirigirá allí
	$id_unico = $facebook->require_login();
 
	if(empty($id_unico))
	{
		// si a estas alturas no tenemos el id único algo ha salido mal
		$error_api = true;
	}
 
?>

Hay varias formas de hacer esto en Facebook, y no digo que esta sea la más correcta, pero seguro que la más sencilla. La importante es la línea 14, en la que si el usuario está logueado nos devolverá su id único, y sino le enviará a la página de login de Facebook.

Yahoo

Otra API con integración no traumática gracias a la tecnología BBAuth de Yahoo. Aquí también se pueden elegir varias implementaciones (OAuth, OpenID), pero de nuevo vamos a optar por la más sencilla y rápida de desarrollar. Los pasos son los siguientes:

1. Vamos a la página de alta de aplicaciones (se necesita usuario de Yahoo).
2. Creamos una nueva Browser-Based Authentication Protected Application

   

3. Nos pedirán confirmar el dominio subiendo un fichero determinado a nuestra web.
4. Nos bajamos la librería cliente de PHP.
5. ¡Y a picar!

Resumiendo de nuevo, tenemos la aplicación creada, apuntadas las dos keys que necesitamos y la clase para comunicarnos con Yahoo (usaremos el fichero ybrowserauth.class.php4 o ybrowserauth.class.php5 dependiendo de nuestra versión de PHP). El código final quedará así:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<?php
 
	// datos de la aplicación que se nos facilitan cuando la registramos en Yahoo
	define('APPID','000000000000');
	define('SECRET','111111111111');	
 
	// cargamos la clase que nos proporcionan (en este caso tenemos PHP 5 en el servidor)
	require_once('apis_externas/yahoo/ybrowserauth.class.php5');
 
	// inicializamos el objeto de la clase
	$authObj = new YBBauthREST(APPID,SECRET);
 
	if(empty($_GET['token'])) 
	{
		// si no tenemos token mandamos a la página de login
		$url = $authObj->getAuthURL('',true);
		header('Location: '.$url);
		exit;
	}
 
	if($authObj->validate_sig()) 
	{
		// si validamos el token ya podemos sacar el id único
		$id_unico = $authObj->userhash;
	}
	else
	{
		// el token recibido no es correcto
		$error_api = true;
	}
 
?>

Es muy importante recordar que esta API es especial en el sentido que el id que se recibe finalmente es un hash del id único real del usuario en Yahoo y el id de la aplicación, es decir, si el mismo usuario de loguea con otra aplicación recibiremos un hash distinto, por lo que tenemos que tener en cuenta qué significa exactamente este id único que recibimos de la API.

Windows Live

Haciendo honor a su fama, y con mucha diferencia, la API de Windows Live es la más complicada de implementar, tanto por su horrenda documentación (lo de msdn es terminal…) como por el engorro general que supone lidiar con sus múltiples archivos y su extraño flujo de información.

Los pasos iniciales son similares a las anteriores APIs, la diversión viene después…

1. Vamos a la página de alta de aplicaciones (se necesita usuario de Windows Live).
2. Creamos un proyecto de Live Services: Existing APIs

   

   Es en este formulario cuando nos enfrentamos al primer problema absurdo, y es que el campo Return URL permite un máximo de 50 caracteres wtf?? cualquier ruta que no vaya a la raíz va a tener más de 50 letras! la única solución es tener una herramienta tipo firebug para poder editar online el HTML y cambiar el atributo maxlength del campo para poder enviar una URL en condiciones (lo que confirma lo absurdo de la limitación es que la página no te comprueba si has escrito más de esos 50 caracteres, se envía sin problemas…)
   Y atención también que la URL de retorno no es la misma que el resto de las APIs, es a un script que nos bajaremos luego con el SDK.

3. Nos bajamos el Web Authentication SDK para el lenguaje que vayamos a utilizar.
4. ¡Y a picar!

De nuevo tenemos una api key, otra key privada, hemos especificado una URL de retorno nueva, y tenemos su SDK con varios archivos. Lo primero es poner las keys en el fichero Application-Key.xml (debe ser innaccesible desde internet, bien limitándolo con un htaccess o colocándolo fuera del document root):

1
2
3
4
5

<windowslivelogin>
	<appid>000000000000</appid>
	<secret>111111111111</secret>
	<securityalgorithm>wsignin1.0</securityalgorithm>
</windowslivelogin>

Ahora en el directorio sample tenemos una implementación de ejemplo a la que podemos quitarle bastante paja. Lo primero es editar el fichero settings.php:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
 
	// por si las cosas no salen y se necesita consultar logs de errores 
	$DEBUG = false;
 
	// path completo al XML de configuración de la aplicación
	$KEYFILE = '/home/usuario/Application-Key.xml';
 
	// nombre de la cookie que almacena el token de usuario que manda la API
	$COOKIE = 'webauthtoken';
 
	// URL a la que tiene que redirigir cuando todo termine
	$INDEX = '/login_externo.php';
 
	// páginas a las que tiene que llevar cuanto se haga login o logout
	$LOGIN = $INDEX;
	$LOGOUT = $INDEX;
 
	// la URL de la API ¡no tocar!
	$CONTROLURL = 'http://login.live.com/controls/WebAuth.htm';
 
?>

En el fichero webauth-handler.php (recordar que es éste el que hemos puesto como URL de retorno al crear la aplicación) tenemos que poner la rutas correcta al fichero de configuración y a la librería de la API (el fichero windowslivelogin.php en el directorio lib):

1
2
3
4
5
6
7
8
9

<?php
 
	require('/home/usuario/dominio/windows_live/settings.php');
 
	require('/home/usuario/dominio/windows_live/lib/windowslivelogin.php');
 
	....
 
?>

Y finalmente el código que implementa la autenticación con Windows Live:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

<?php
 
	// el fichero de configuración de la API
	require('/home/usuario/dominio/windows_live/settings.php');
 
	// la librería del SDK
	require('/home/usuario/dominio/windows_live/lib/windowslivelogin.php');
 
	// inicializamos las variables
	$wll = WindowsLiveLogin::initFromXml($KEYFILE);
	$wll->setDebug($DEBUG);
	$APPID = $wll->getAppId();
	$userid = null;
 
	// comprobamos si el token de usuario está en la cookie
	$token = @$_COOKIE[$COOKIE];
	if(!empty($token))
	{
		$user = $wll->processToken($token);
		// tenemos token, intentamos sacar de él el id único del usuario
		if(!empty($user))
		{
			$userid = $user->getId();
		}
	}
 
	if(!empty($userid))
	{
		// guardamos el id único
		$id_unico = $userid;
	}
	else
	{
		// si no tenemos token, redirigimos al usuario a la página de login de Windows Live
		header('Location: http://login.live.com/wlogin.srf?appid=0000000040009631&alg=wsignin1.0');
		exit;
	}
 
?>

Quedaría, como en el resto de APIs, hacer una gestión eficiente de los errores que se pueden dar, aunque eso ya son detalles de implementación de cada aplicación.

Tampoco comento nada sobre los módulos de PHP que es necesario tener activados en el servidor para hacer funcionar las APIs. En principio los únicos que considero pudieran salirse de una configuración básica son curl y mhash. Curl se utiliza en la librería de Yahoo y es complicado buscarle una alternativa. Mhash se utiliza en la de Windows Live, y en este caso, siendo una extensión mucho menos común, se puede puentear su uso parcheando el fichero windowslivelogin.php, en concreto la línea:

1515

$key = mhash(MHASH_SHA256, $key);

Cambiándola para utilizar funciones del core de PHP5 que también realizan el hash binario SHA256:

1515

$key = pack("H*", hash('sha256', $key));

Entradas relacionadas:

1. Windows Live Maps: Sé un Pájaro
2. Segundo Facebook Developer Garage en Madrid
3. Nuevas APIs de Google

Estoy viciado a tumblr, enganchado a su sencillez, encantado con su filosofía y alucinando con su comunidad.

• Es sencillo como pocas cosas compartir lo que quieras en tu tumblr. Tienes un dashboard con enlaces según el tipo de contenido que quieres publicar y poco más. Rellenas un campo (dos si eres pro) y de las al botón de Create post. Hay extensiones de firefox que lo hacen tan trivial como arrastrar el contenido a un icono de tu barra de estado. Y sí, la sencillez crea adicción (¿he oído twitter?)
• tumblr es la quintaesencia de la filosofía del tumblelog, el término medio entre el blog de toda la vida y el nuevo microblogging, un espacio sin necesidad de temática fija, sin los rigores de un post más trabajado y con ese plus multimedia que a veces se echa en falta en el nanoblogging. No hay comentarios, no hay categorías ni tags… es una servilleta de papel de un bar en la que apuntas lo que te viene a la cabeza, lo que encuentras, lo que te gusta… y es tu servilleta, porque las posibilidades de personalización son totales (ver ejemplos).
• Y sin duda lo que más me ha sorprendido es la comunidad. Me recuerda la sensación que tengo cuando navego por Vimeo, todo parece de tanta calidad y veo tan poca morralla que me da que pensar si estas comunidades se forman de manera espontánea o la supuesta navegación por el portal es en realidad una visita guiada a través de un filtro anti-shit. Una muestra en el Radar y el Directorio.

  Otro plus es que es una comunidad activa (cosa que no me extraña). En tu dashboard puedes ver las actualizaciones de los tumblrs que sigues (otro vicio), y continuando con la sencillez, puedes rebloguear ese contenido o guardártelo como favorito. Todo esto para comentar que he visto como un usuario (que digo yo será bastante popular) ha colgado una foto y al minuto tenía más de 20 reblog/likes. Lástima que en castellano hayan tan pocos (bueno, tampoco me he puesto a buscar, me vale con las joyitas que voy encontrando) tumblrs…

En definitiva, para mi tumblr ha supuesto el complemento perfecto a este blog y mi tuiter. La puntilla ha sido cuanto el otro día lanzaron la integración oficial con twitter, justo en el clavo, es exactamente uno de los usos que me gusta darle al microblogging, compartir cosas que me voy encontrando en las navegaciones a la deriva… ahora por fin tengo la perfecta servilleta de papel para apuntarlos y que no se pierdan en la niebla de mi historial!

Para terminar, unos cuantos tumblrs: yimmyayo, hipstertracks, graphiceverywhere, kari-shma… y por supuesto el mio!! micro usuario de internet!!

Durante estos días uno no hace más que ver en Internet referencias al nuevo killer service, venerado por la blogosfera y los early adopters (frikis para los profanos), Spotify, o como dar un vuelco al negocio de la música en Internet por la patilla.

Y es que el temita promete. El otro día conseguí una invitación (ahora mismo está en beta semi-pública) sin saber qué leches iba a probar, y sin ser usuario de servicios tipo last.fm, pandora, etc… vamos, yo soy de los del género vago, de abrir la radio online a las 9:00 y no cerrarla hasta las 19:00. Pero es que ésto está tan bien hecho, es tan sencillo, tan fluido, que crea adicción, incluso en analfabetos musicales de mi calaña. Primer logro.

El servicio va de: A. Registrarse B. Instalarse su aplicación C. ¡Música! (it’s easy as 1,2,3!). La herramienta es una maravilla, un iTunes fibrado y ligero, diseño minimalista y usabilidad cuidada. Cualquier camino dentro de la aplicación termina siempre en escuchar música. Haces click en el nombre de un artista, vas a su ficha, ves toda su discografía, clickeas el track 9 del CD2 de su disco de hace 7 años y lo escuchas. TODA canción que aparezca en la aplicación simplemente haces click y la escuchas. Música gratis bajo demanda.

No voy a analizar sus pros y contras, para eso ya sabéis que hay otras webs temáticas, sólo comentar lo que me siguen sorprendiendo algunos modelos de negocio en Internet. En algo como la música, con unos proveedores que odian y desprecian al medio, y unos márgenes pírricos (creo recordar que si en iTunes una canción costaba 0.99 €, las majors se llevaban 0.70 €), no me parece muy sostenible la apuesta de Spotify, con un modelo freebie totalmente funcional (si el modelo premium lo único que me ofrece es que no me salgan ads sonoros, poco van a sacar por ahí), unos ingresos por publicidad tipo radio (¿éso lo sigue contratando alguien?) y un coste asociado al ancho de banda de servir las canciones (aunque utilicen un modelo híbrido P2P). Tal vez sea lo que se comenta por ahí, que es un torpedo con el que la industria discográfica (¿tal vez hayan aceptado menos trozo de la tarta por el compromiso de los responsables del proyecto de que algo va a cambiar?) quiere atacar a la línea de flotación de la piratería musical: “Tú, alma triste, si te pongo un programita con el puedes escuchar cualquier canción como si la tuvieras descargada ¿pa que leches quieres seguir dándole al emule?”

Y bueno, no tendrán la parte social muy desarrollada, pero en Twitter por ejemplo no paran ya de llover los enlaces para escuchar canciones. Comparto un temazo: http://open.spotify.com/track/40ThmAgDduNcjwkypLe0Dj

Por cierto, tengo unas cuantas invitaciones para probar Spotify, aunque no se si es una puerta trasera dejada abierta disimuladamente aposta o están en la parra, pero por ahora te puedes registrar sin invitación aquí. ACTUALIZACIÓN: parece ser que dicha puerta ha sido cerrada, de todas formas yo sigo teniendo unas cuantas invitaciones, si lo necesitas escribe un comentario.

su vídeo promocional

adoremos al pixel

Entradas relacionadas:

1. Semana 1 / Feed Dispatching
2. Semana 2 / El Cerebro de la Bestia