Vamos a configurar el componente Auth de CakePHP en cinco pasos; es decir, en un plisplás. Este ejercicio supone que no hemos creado el modelo Usuario y su tabla correspondiente, así que lo haremos por el camino. Are you ready? Sí? 1, 2, 3… Go!

1. Copia el siguiente código.

function inicializarAuth(){
   $this->Auth->userModel = 'Usuario';
   $this->Auth->fields = array('username' => 'login', 'password' => 'password');
   $this->Auth->loginAction = array('controller' => 'usuarios', 'action' => 'login');
   $this->Auth->loginRedirect = array('controller' => 'usuarios', 'action' => 'index');
   $this->Auth->logoutRedirect = array('controller' => 'pages', 'action' => 'display');
   $this->Auth->loginError = 'El nombre de usuario y/o la contraseña no son correctos. Por favor, inténtalo otra vez';
   $this->Auth->authError = 'Para entrar en la zona privada tienes que autenticarte';
   $this->Auth->allow('registro');
   $this->Auth->allow(array('display'));
   $this->Session->write('Auth.redirect', null);
} // fin de function inicializarAuth
function beforeFilter(){
   $this->inicializarAuth();
} // fin de function beforeFilter()

2. Copia el archivo /cake/libs/controller/app_controller.php en /app/app_controller.php. Ahora, edita el recién creado /app/app_controller.php y pega el código que has copiado antes en el interior de la clase AppController. Cuando tu clase AppController quede como la del siguiente ejemplo, guárdala sin miedo. Date prisa.

 class AppController extends Controller {
   var $components = array('Auth');
   function inicializarAuth(){
      $this->Auth->userModel = 'Usuario';
      $this->Auth->fields = array('username' => 'login', 'password' => 'password');
      $this->Auth->loginAction = array('controller' => 'usuarios', 'action' => 'login');
      $this->Auth->loginRedirect = array('controller' => 'usuarios', 'action' => 'index');
      $this->Auth->logoutRedirect = array('controller' => 'pages', 'action' => 'display');
      $this->Auth->loginError = 'El nombre de usuario y/o la contraseña no son correctos. Por favor, inténtalo otra vez';
      $this->Auth->authError = 'Para entrar en la zona privada tienes que autenticarte';
      $this->Auth->allow('registro');
      $this->Auth->allow(array('display'));
      $this->Session->write('Auth.redirect', null);
   } // fin de function inicializarAuth
   function beforeFilter(){
      $this->inicializarAuth();
   } // fin de function beforeFilter()
}

3. Ahora tenemos que crear el modelo Usuario. Para ello, ve a /app/models y crea el archivo usuario.php con el siguiente código. ¡Corre!

class Usuario extends AppModel{
   var $name = 'Usuario';
   var $validate = array(  'login' =>     array(
                                                'rule' => array('minLength', 1),
                                                'required' => true,
                                                'allowEmpty' => false,
                                                'message' => 'Por favor, introduce el login'
                                             ),
                           'password' =>  array(
                                                'rule' => array('minLength', 1),
                                                'required' => true,
                                                'allowEmpty' => false,
                                                'message' => 'Por favor, introduce la contraseña'
                                             ),
                           'email' =>     array(
                                                'rule' => 'email',
                                                'required' => true,
                                                'allowEmpty' => false,
                                                'message' => 'Por favor, introduce una dirección de correo válida'
                                             )
                     );

}

4. Una vez tenemos el modelo Usuario, escribimos el SQL que crea usuarios, su tabla correspondiente. ¡Ya casi está!

create table usuarios(

id mediumint unsigned NOT NULL auto_increment,

login varchar(20) NOT NULL,

email varchar(100) NOT NULL,

data datetime NOT NULL,

password varchar(40) NOT NULL,

primary key(id)

);

5. Finalmente, como estamos hechos unos campeones, nos tomamos un kit kat.

Qué hemos hecho?

Working like a machine? Muy buenas de nuevo, hemos vuelto de la publicidad y ahora es el momento de ver qué hemos hecho exactamente.

Paso 1

Aquí sólo hemos copiado un trozo de código; luego veremos qué hace exactamente. De momento, empero, vamos a intentar desentrañarlo un poco.

Los componentes de CakePHP encapsulan lógica que van a compartir varios controladores. En particular, Cake viene de fábrica con el componente Auth, cuya razón de ser es autenticar a los usuarios de una aplicación CakePHP. Como veremos un poquito más adelante en esta explicación, cuando añadimos el componente Auth al programa, entonces, de forma predeterminada, se bloquean todas las acciones a excepción de login y logout.

Paso 2

Todos los controladores de la aplicación Cake extienden la clase AppController; en consecuencia, si queremos añadir algo que compartan todos ellos, debemos hacerlo aquí. Por eso, estimado visitante, primero nos hemos ido a /cake/libs/controller/app_controller.php, luego hemos copiado este archivo en /app/app_controller.php, y, finalmente, hemos pegado el código aquí. ¿Quieres saber por qué es necesaria esta copia de app_controller.php? Haz clic aquí, pues.

En efecto, querido Watson, en AppController hemos añadido el componente Auth y lo hemos configurado en el método beforeFilter(). Por cierto, recordemos que beforeFilter() es una acción callback que se ejecuta justo antes de llamar a cualquier acción del programa CakePHP. Elemental. Bueno, visitante, en realidad bromeo un poco y puede que esto no sea tan elemental. Puedes echar un vistazo a las retrollamadas en http://book.cakephp.org/es/view/60/Callbacks.

Sin embargo, la dificultad de este paso número dos se encuentra en la función inicializarAuth porque es aquí donde debemos definir las propiedades del componente y esto implica que las conocemos. Quiero decir, que para escribir esta función tenemos que conocer un poco a Auth para decirle lo que queremos hacer con él. Vamos a hacerlo ahora.

Por defecto, la tabla donde se almacenan los usuarios se llama users, pero no siempre es así. Si quieres utilizar otra configuración puedes utilitzar los pasos 3 y 4 de este ejercicio, ¡pero recuerda decírselo a Auth en el beforeFilter! Por ejemplo, para utilizar el modelo Usuario, escribimos esto:

$this->Auth->userModel = 'Usuario';

Por otra parte, Auth espera que los campos que almacenan el nombre de usuario y la constraseña se llamen username y password y para decirle, “Oye, por favor, Auth, fíjate que, en vez de username y password, mi tabla usuarios tiene los campos login y password. Gracias”, escribimos esta línea:

$this->Auth->fields = array('username' => 'login', 'password' => 'password');

Esta línea le dice a Auth dónde está la acción que autentica a los usuarios:

$this->Auth->loginAction = array('controller'=>'usuarios','action'=>'login');

 Y esta otra, dónde debe redireccionar a los usuarios que salen correctamente del sistema: 

$this->Auth->logoutRedirect = array('controller'=>'pages', 'action'=>'display');

Estas dos tienes que adivinarlas tú: 

$this->Auth->loginError('El nombre de usuario y/o la contraseña no son correctos. Por favor, inténtalo otra vez';
$this->Auth->authError('Para entrar en la zona privada tienes que autenticarte');

¿Recuerdas que decíamos que cuando añadimos el componente Auth en AppController se bloquean todas las acciones a excepción de login y logout? Pues bien, si nos interesa desbloquear otras acciones para hacerlas accesibles a todos los visitantes del sitio web, entonces utilizamos la variable allow. Un caso típico es el de la acción que permite que los usuarios se puedan registrar. Efectivamente, si queremos que todo el mundo pueda acceder, entonces escribimos esto:

$this->Auth->allow('registro');

Si queremos que la vista /app/views/pages/home.ctp también esté disponible, escribimos:

$this->Auth->allow(array('display'));

Auth se comporta de forma que recuerda y redirecciona al URL al que el usuario intentaba acceder antes de entrar correctamente en el sistema. Por ejemplo, si el usuario escribe www.miaplicacioncakephp.com, y, a continuación, entra en www.miaplicacióncakephp.com/usuarios/login y se autentica, Auth no le envía a la vista login.ctp, como muchos podríamos esperar, sino a index.ctp. Esta dirección se guarda en la variable de sesión Auth.redirect; para deshabilitar este comportamiento, escribimos esto (hay una discusión interesante al respecto en http://book.cakephp.org/comments/index/392):

$this->Session->write('Auth.redirect',null);

Pasos 3 y 4

En estos pasos hemos creado el modelo Usuario y la tabla usuarios porque en este ejemplo no nos interesa seguir las convenciones de CakePHP y utilizar el modelo User y su tabla correspondiente, users. Finalmente, recordamos otra vez que, haciendo esto, es necesario comunícarselo a Auth; en concreto, como hemos visto, esto se hace a través de las variables userModel y fields.

Resumen

En este post hemos visto que los controladores de CakePHP extienden la clase AppController y que si queremos que una lógica determinada esté disponible en todos los controladores de la aplicación entonces debemos añadirla a la clase /app/app_controller.php.

CakePHP viene de fábrica con el componente Auth, y cuando lo añadimos en AppController se bloquean todas las acciones de todos los controladores a excepción de login y logout.

Para configurar Auth debemos conocer los parámetros de que dispone: userModel, fields, loginAction, allow, etc. En cualquier caso, todos ellos se parametrizan enel método beforeFilter de AppController porque esta acción se ejecuta antes de cualquier acción de la aplicación CakePHP.

Nota:

Ha pasado un tiempo desde que escribí en este blog el post http://tutorialcakephp.wordpress.com/2008/11/20/20-de-noviembre-de-2008-de-cakephp-11-a-cakephp-12-el-baile-de-los-errores-parte-ii/. Aquí explicaba mi primer acercamiento al componente Auth. ¡Espero que este otro lo encuentres un poco mejor y te sea más útil!

Esta tarde me he dedicado a validar las páginas XHTML de mi aplicación CakePHP con http://validator.w3.org/, el servicio de validación de marcado del W3C (W3C Markup Validation Service) pero… ¡sorpresa!: resulta que, al principio, no podía hacerlo porque había olvidado añadir la declaración del tipo de documento justo al comienzo de éstas. Resultado: el mensaje de error del título de este párrafo.

Confieso, pues (no se lo digas a nadie), que hasta hace muy poco no tenía claro qué era el DOCTYPE. Aunque lo he añadido algunas veces (justo antes de validar el código de turno), siempre lo he dejado para el final y esta vez se me había olvidado. ¿Qué tal si rescatamos al DOCTYPE del olvido y lo ponemos siempre al principio del archivo a partir de ahora? Seguro que es una buena idea. Todo esto si tú hacías como yo, claro.

En concreto, el mensaje que lanza el http://validator.w3.org/es es algo así como este: “No se ha podido encontrar o no se ha reconocido una declaración de tipo de documento en este archivo. Generalmente, esto significa que, al principio, el documento no declara su tipo de documento. También puede ser que haya un error en la declaración o que no esté utilizando la sintaxis correcta”.

A continuación, el programa verifica el documento como si se tratara de un HTML 4.01 Transitional.

1. ¿Qué es el DOCTYPE?

Dejando a un lado algunos aspectos más o menos técnicos y profundos que he encontrado en Internet (que no sé si comprendo del todo), según lo que muchos dicen y sí que entiendo, el DOCTYPE es algo así como una instrucción que tiene que ponerse al comienzo del documento (X)HTML para que el navegador sepa qué va a encontrarse a continuación y pueda interpretarlo en consecuencia. La mayoría de explicaciones que he leído coinciden en que el DOCTYPE no es una etiqueta, sino “una declaración”. A continuación, adjunto esta explicación de www.eslomas.com, que está muy bien:

“El DOCTYPE es una parte fundamental de todas aquellas páginas que quieran cumplir los estándares, tanto HTML como XHTML. Esta declaración indica que versión de (X)HTML se usa en la página, de forma que los navegadores pueden saber qué sintaxis y gramática se usa, y los validadores puedan comprobar su validez.[...] Aparte de esto la declaración DOCTYPE se utiliza por los navegadores para activar su modo estándar o estricto, o su modo compatibilidad (quirk)”.

Esto mismo explica el mismo W3C en este documento. Ciertamente, no debemos olvidar añadir el doctype porque las herramientas que procesan los documentos HTML necesitan conocer el DTD que utilizan los documentos. Esta es una información clave que necesitan los navegadores y las herramientas que procesan el documento; por ejemplo, el servicio de validación de marcado del W3C.

Por último, los navegadores interpretan el documento más rápidamente y de una forma más consistente cuando se define el doctype; es decir, analizan sintácticamente el archivo en modo estándar y no tienen que “hacer conjeturas”. El resultado: nos evitamos sorpresas.

2. ¿Qué declaraciones de tipo de documento podemos utilizar?

Hay una lista del W3C con todas ellas, http://www.w3.org/QA/2002/04/valid-dtd-list.html.

3. ¿Cómo se escribe una DTD en CakePHP?

Se utiliza $html->docType() para escribir la declaración del tipo de documento. En función del DTD que queramos utilitzar, se usa el parámetro correspondiente: html, html4-strict, html4-trans, xhtml-strict, etc. Todos estos parámetros están en http://book.cakephp.org/view/206/Inserting-Well-Formatted-elements, el manual de CakePHP.

Por ejemplo, como la sintaxis que usan mis documentos es la XHTML 1.0 Strict, he escrito este código en el archivo /layout/default.ctp de mi aplicación CakePHP:

<?php 

echo $html->docType('xhtml-strict'); 

?>

Si ahora ejectuo el programa y visualizo el código fuente de cualquier página, entonces ya aparece la DTD antes de la etiqueta <html>:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

Finalmente, si vuelvo a validar el código de la página, en http://validator.w3.org/, me sale este otro mensaje:

Errors found while checking this document as XHTML 1.0 Strict!

Es decir, el validador, que reconoce la sintaxis de mi archivo, encuentra varios errores en él. No obstante, como diría Michael Ende en La Historia Interminable, esa es otra historia que debe ser contada en otra ocasión.

Sí, como también coincide que últimamente me ha dado por escuchar a Couperin (a quien recién descubrí, por cierto), inserto a continuación este video que espero que te guste. A ver si su música nos ayuda a estimular el sistema cognitivo y nuestras aplicaciones AJAX dejan de lanzar errores por todas partes, como las mías ahora.

Pero vayamos al grano. Resulta que estoy trabajando en un juego multiusuario que implementa la técnica AJAX polling. Por cierto, estoy casi convencido de que sería mejor utilizar otras técnicas -long polling, sockets o COMET- pero finalmente utilizo esta porque para mí es la más sencilla. Bueno, también me tranquilizó un poco saber que esto puede hacerse así y que está muy bien para acercarse a AJAX long polling y a COMET.

¿Qué es AJAX polling?

AJAX polling es una técnica de programación que consiste en solicitar a intervalos de tiempo regulares la ejecución de la lógica determinada que implementa el servidor. El principal inconvieniente de esta técnica es su escalabilidad porque el número de peticiones puede llegar a incrementarse drásticamente si ese intervalo regular de tiempo es pequeño. Por ejemplo, si hay 1000 usuarios conectados a la aplicación y cada uno de ellos hace una petición por segundo, entonces el servidor recibe 2000 peticiones por segundo.

Además de esto, otra de las desventajas de AJAX polling es que el servidor siempre responde a las peticiones que recibe de los clientes, independientemente de si tiene alguna información nueva que entregarles. En otras palabras, los clientes siempre ejecutan la lógica de turno (actualizan la página cada segundo, por ejemplo) cada n segundos aunque no sea necesario.

Implementación de AJAX polling con CakePHP

Finalmente, mi aplicación multiusuario tiene varias tablas a las que acceden los jugadores de forma dinámica. Además de consultar y actualizar estas tablas, los jugadores calculan sus puntuaciones a partir de ellas y las visualizan en su pantalla en tiempo real. He implementado esta idea utilizando el método remoteTimer:

   echo $ajax->remoteTimer (  array(   'url' => array('controller' => 'multijugadores', 'action' => 'preguntar_sistema'),
                                       'update' => 'aciertos',
                                       'frequency' => 1
                                    )
                           );

Este método, envoltorio de los objetos Prototype PeriodicalExecuter y Ajax.Updater, pide cada segundo la ejecución de la acción preguntar_sistema. Esta acción es la que se encarga de realizar las consultas a las tablas comunes (un conjunto de tablas que todos los usuarios comparten) e imprimir las puntuaciones, calculadas a partir de éstas.

Estoy trabajando en local, la aplicación funciona y de momento no sé qué consecuencias puede tener esta implementación en el rendimiento del servidor compartido al que estoy a punto de subirla. ¿Tienes alguna experiencia con aplicaciones de este tipo? Si es así, cuéntanos… ;-)

¿Y la música… De dónde sale?

Bueno, compi, pues Couperin aparece para ayudarme a abordar el problema de una forma no racional. Me refiero al problema de definir la idea de la aplicación multiusuario. Sí, Couperin es la fuente de inspiración que ha derribado las barreras lógica, hipotética y deductiva de la perspectiva izquierda de mi pensamiento y me ha ayudado a crear la idea. Seguro que las hay mejores (¡explícanos alguna, si las conoces!), pero estoy contento porque esta funciona. Espero que te animes a probarla y, si quieres, la comentamos aquí.

¿Qué es un datasource?

Los desarrolladores de CakePHP han creado varios recursos que sirven para extender la funcionalidad de las diferentes partes de una estructura MVC con el objetivo de mantener bien organizado el código de los modelos, las vistas y los controladores.

En efecto, cuánto más crece la complejidad de una aplicación, es más difícil mantener bien organizado el código de los archivos. Los helpers, por lo tanto, ayudan a mantener bien organizado el código de las vistas; los componentes, el de los controladores; finalmente, los datasources y los behaviors nos ayudan con los modelos.

Funcionamiento de los datasources

Como hemos dicho, los datasources extienden la funcionalidad de los modelos para que estos últimos no tengan que preocuparse de montar las consultas SQL y de realizar las operaciones de conexión con la base de datos. En otras palabras, los datasources actúan como una capa situada entre el modelo y la fuente de datos (MySQL, PostgreSQL, Oracle, XML, etc).

Veamos cómo trabajan juntos el modelo y el datasource a través de un ejemplo concreto en que la fuente de datos es una base de datos MySQL. En este caso, el modelo ejectua una de sus  funciones (find, por ejemplo); el datasource la recoge, arma una cadena SQL y se conecta a la base de datos; a continuación, el datasource recoge el conjunto resultado de MySQL, le da formato y devuelve el resultado al modelo.

Creación del datasource YoutubeSource

Del mismo modo que los helpers se crean en la carepta app/views/helpers y los controladores se crean en app/controllers/components, los datasources se crean en la carpeta app/models/datasources.

Nuestro datasource para YouTube es este:

class YoutubeSource extends DataSource{
   var $description = 'Fuente de datos YouTube';
   var $respuestaYoutube;
   function __construct($config=null){
      parent::__construct($config);
      $this->connected = $this->connect();
      return $config;
   }
   function __destruct(){
      $this->connected = $this->close();
      parent::__destruct();
   }
   function connect(){
      $apiURL = 'http://gdata.youtube.com/feeds/api/standardfeeds/most_viewed';
      $ch = curl_init();
      $timeout = 0;
      curl_setopt($ch, CURLOPT_URL, $apiURL);
      curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
      curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
      $this->respuestaYoutube = curl_exec($ch);
      curl_close($ch);
      if (!$this->respuestaYoutube){
         return false;
      } else {
         return true;
      }
   }
   function close(){
   }
   function read(){
   }
   function query(){
   }
   function describe(){
   }
   function column(){
   }
   function isConnected(){
   }
   function showLog(){
   }
   function videosMasVistos(){
      App::import('Core','Xml');
      return Set::reverse(new Xml($this->respuestaYoutube));
   }
}

He seguido el capítulo 14 del libro Beginning CakePHP From Novice to Professional de David Golding para hacer este ejercicio. En él, David Golding nos indica que es necesario definir un esqueleto mínimo con las funciones __construct(), __destruct(), connect(), close(), read(), query(), describe(), column(), isConnected() y showLog().

YoutubeSource implementa el método connect() y hace una llamada al API REST de YouTube para obtener el feed Atom con la información de los vídeos más vistos. Por otra parte, como veremos un poco más adelante cuando creemos el modelo YouTube, también implementa el método videosMasVistos(). 

La clase del datasource se llama YoutubeSorce y tiene que guardarse en el archivo youtube_source.php de la carpeta app/models/datasources.

Incluir nuestro datasource en app/config/database.php

Del mismo modo que los ayudantes y los componentes se incluyen en las matrices $helpers y $components del controlador, respectivamente, los datasources se definen en la clase DATABASE_CONFIG de app/config/database.php.

Efectivamente, para incluir el datasource que acabamos de crear en nuestra aplicación CakePHP podemos escribir lo siguiente justo después de la declaración de $default:

var $youtube = array(
  'datasource' => 'youtube'
 );

Creación del modelo Youtube y del método feedsMasVistos()

Ahora tenemos que crear la tabla youtubes en nuestra base de datos y el modelo YouTube en app/models/youtube.php.

class Youtube extends AppModel{
   var $name = 'Youtube';
   function videosMasVistos(){
      $this->setDataSource('youtube');
      $youtube = $this->getDataSource();
      return $youtube->videosMasVistos();
   }
}

Último paso: llamar al método videosMasVistos en el controlador y crear la vista

Finalmente, ya podemos probar nuestro datasource. Para ello tenemos que llamar desde el controlador al método videosMasVistos() del modelo YouTube:

$this->set('feedAtom', $this->Youtube->videosMasVistos());

También hay que crear la vista app/views/youtube/mas_vistos.ctp para mostrar el resultado en la pantalla:

[/sourcecode language='php']

echo ‘<h3>Los videos más vistos son…</h3>’;
foreach ($feedAtom->entry as $entry){
echo $entry->title.’<br/>’;
}

[/sourcecode]

¡Y esto es todo! Espero que este post te haya gustado, lo encuentres útil, y te sirva para dar tus primeros pasos con los datasources.

¿Qué tal si hacemos clic en los dos y los vemos al mismo tiempo? A mí me ha ido muy bien leer lo que dice uno y compararlo en el otro. Hueniverse explica, a través de los programas de ejemplo faji y beppa, cómo ve el usuario el proceso OAuth (personalmente me ha gustado mucho y lo encuentro muy práctico y sencillo). Por otra parte, el enlace de La guía del desarrollador de Google es bastante más técnico y presenta, en 14 pasos, el diagrama de flujo del proceso OAuth. En un contexto CakePHP y YouTube, mi resumen sería este:

El programa CakePHP pide a Google un token de autorización; éste nos lo envía, pero antes comprueba que estamos registrados; nuestra aplicación web redirecciona al usuario a la página de YouTube y el usuario se autentica; el token de autorización se convierte entonces en un token de acceso y YouTube redirecciona al usuario a nuestra página CakePHP; CakePHP se conecta a YouTube para intercambiar el token de autorización por el de acceso y YouTube se lo devuelve; finalmente, cuando se asocia el token de acceso a la cuenta de YouTube del usuario, el programa ya puede enviar peticiones API autenticadas en nombre del usuario. ¡Puf! ¡Parece la jugada de un partido de fútbol!

Estas son algunas definiciones de los conceptos básicos que maneja OAuth según la Guía de OAuth para principiantes. Estos conceptos son los mismos que trata la especificación técnica del protocolo OAuth 1.0, publicada el 4 de diciembre de 2007.

Proveedor del servicio. El proveedor del servicio controla todos los aspectos de la implementación OAuth. Este término se utiliza para describir el sitio o servicio web donde se encuentran los recursos restringidos. Puede tratarse de un sitio para compartir fotos donde los usuarios guardan sus álbumes, un servicio de banca en línea, un sitio de microblogging, o cualquier otro servicio que almacene material privado del usuario.

Usuario. Es la razón de ser de OAuth. Si no hay usuarios, no hay necesidad de OAuth. Los usuarios tienen material privado en el proveedor del servicio pero quieren compartirlo con otro sitio. En OAuth, el protocolo se detiene, sin intervención manual con el usuario, al menos una vez, para recibir el permiso que otorga el acceso.

Consumidor. Un nombre curioso para una aplicación que intenta acceder a los recursos del usuario. Puede ser un sitio web, un programa de escritorio, un dispositivo móvil o cualquier cosa conectada a Internet. El consumidor es el que pide permiso para acceder a los recursos y es aquí donde se lleva a cabo la parte más útil de OAuth. OAuth define un desarrolador de consumidor como la entidad que escribe código que interactúa con el proveedor del servicio.

Recursos protegidos. Es el material que protege OAuth y al que permite el acceso. Pueden ser datos (fotos, documentos, contactos), actividades (el post de un blog, fondos de transferencia) o cualquier URL que necesite restringir el acceso.

Tokens. Para acceder a los recursos se utilizan tokens en vez de credenciales de usuario. Generalmente, un token es una cadena aleatoria, única, de letras y números, difícil de adivinar, que forma pareja con un secreto que protege al token de los malos usos. OAuth define dos tipos diferentes de tokens: tokens de petición y tokens de acceso.

La autenticación OAuth es el proceso mediante el que los usuarios de nuestra aplicación CakePHP conceden acceso a sus recursos protegidos de YouTube sin compartir sus credenciales con nosotros. Gracias a este protocolo, los programas pueden acceder a través de una API a los recursos protegidos que sus usuarios tienen en otros sitios.

Funcionamiento de OAuth desde el punto de vista del usuario

Supongamos, por ejemplo, que nuestro sitio CakePHP, www.fotosyvideos.com, accede a las fotos que tienen sus usuarios en www.flickr.com, o a los vídeos que tienen en www.youtube.com. Con OAuth los usuarios no tienen que darnos sus credenciales, mientras que sin un protocolo como este el programa pediría el login y password para poder acceder a los datos protegidos proporcionados por Flickr o YouTube.

Todo esto se traduce en más seguridad. Como explica la Guía OAuth para principiantes, dar nuestro nombre de usuario y contraseña a un sitio web para que obtenga de otro sitio web nuestra lista de contactos, es lo mismo que ir a cenar y dar nuestro código al camarero en el momento de pagar con la tarjeta. Ciertamente, los usuarios se arriesgan cuando comparten su información privada con otros sitios o personas. Todo esto y más lo explica muy bien el sitio oficial de OAuth (en inglés).

En resumen, este post presenta el protocolo OAuth, gracias al cual las aplicaciones de escritorio, móviles y web interactúan de forma segura con datos protegidos. Hemos descubierto que este protocolo permite autorizaciones API de forma sencilla, abierta, estándar y segura. Finalmente, al preguntarnos por el funcionamiento de OAuth desde el punto de vista del usuario, hemos visto que es seguro porque éstos no tienen que darnos sus credenciales.

Información de OAuth en español aquí:

http://www.error500.net/oauth-identificacion-abierta

http://www.econectados.com/2007/10/oauth-protocolo-de-autentificacion-segura-para-apis/

http://www.lacofa.es/index.php/tecnologias/futuro-de-internet/oauth-primer-paso-hacia-el-control-de-la-informacion-de-personalizacion

http://www.webmasterlibre.com/2008/06/30/oauth-autenticacion-segura-para-apis/

Otras explicaciones muy buenas sobre este tema: una es es de Nokrosis y el enlace es este; también adjunto este artículo, Servicios Web con PHP, de www.malditainternet.com.

- Wikipedia. La enciclopedia libre

Según esta definición, como la entendía antes de descubrir las APIs Web, me preguntaba lo siguiente: ¿Dónde están las funciones y los procedimientos cuando armo un listado de vídeos de YouTube?, ¿dónde están estas funciones cuando obtengo un Google Maps?

Roy Thomas Fielding y REST

Roy Thomas Fielding es uno de los principales autores de la especificación HTTP (RFC 2616) y obtuvo su doctorado hace nueve años, en 2000, en la Universidad de California, con su tesis Estilos Arquitecturales y el Diseño de Arquitecturas Software basadas en Red. En este trabajo, Fielding presenta la Transferencia de Estado Representacional, o REST (Representational State Transfer).

Para qué sirve REST

Actualmente, el término REST hace referencia a un enfoque para desarrollar y proporcionar servicios web y es una alternativa a los servicios web SOAP. No tengo ninguna experiencia en SOAP y hablaré poco de él para no meter mucho la pata.

Por lo que creo haber entendido, hay muchas diferencias en el funcionamiento de estas dos tecnologías. Por ejemplo, con SOAP, que se basa en RPC, tenemos un conjunto de métodos que hacen algo, mientras que en REST los que hacen algo son los recursos, identificados por un URL.

Qué es un servicio web

Según el W3C: “Un conjunto de aplicaciones o tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web“.

Cómo funcionan las APIs basadas en REST

Bueno, pues las funciones o métodos que yo buscaba ¡son los URL! Si en RPC teníamos métodos como getUser(), addUser() o removeUser(), ahora, en REST, tenemos recursos identificados con URLs. Como explica muy bien la Wikipedia:  “Los clientes trabajan con estos recursos a través de las operaciones estándar de HTTP, como GET para descargar una copia del recurso“.

Más concretamente, esto es lo que se hace aquí, por ejemplo, cuando le pedimos al geocodificador de Google que nos mande un mapa. Esto es lo que hicimos, también, aquí, cuando le pedimos a YouTube que nos mandara un listado con los vídeos más vistos. En ambos casos, la respuesta que recibimos de este recurso es un XML, aunque esto se puede parametrizar en el URL de consulta para que sea, por ejemplo, otra, como JSON.

¿Entonces, qué es el API de YouTube?

No hace mucho, algunas compañías comenzaron a liberar sus APIs: Amazon, Yahoo!, Google, etc. En otras palabras, expusieron sus servicios web en forma de recursos REST, a través de un URL, para que los consumidores de estos servicios (los programadores) pudieran acceder a este procesamiento a través del protocolo HTTP.  El API de YouTube es, pues, un servicio web basado en REST.

Dónde está REST

¿Recuerdas que estos días descubrimos el funcionamiento de los blogs y de los feeds RSS, gracias al videotutorial RSS hablando en plata? ¡Pues resulta que la tecnología que hay detrás de ellos es REST! Ciertamente, los lectores de feeds consultan un URL, el del feed, que devuelve un XML.

Hasta otra

Espero que este post te haya gustado y lo encuentres útil. Ya conocemos un poco mejor qué es esto que andamos tocando (¡APIs REST!) y cómo utilizarlas, que es de lo que se trata; si encuentras algún fallo, ¡deja aquí algún comentario!

Más información de todo este asunto aquí…

http://es.wikipedia.org/wiki/Representational_State_Transfer

http://www.ibm.com/developerworks/xml/library/x-youtubeapi/

http://phpwebservices.blogspot.com/2008/01/rest-with-php_20.html

www.di.uniovi.es/~cueva/asignaturas/doctorado/2006/trabajos/Ponencia%20REST.pdf

http://es.wikipedia.org/wiki/Roy_Fielding

http://www.sematopia.com/?p=153