Archive for category Programación Web
Amazon AWS anuncia la afinidad de servidores en Elastic Load Balancing
Posted by Xavi in Programación Web on 08/04/2010
Uno de los problemas más importantes que existían para desarrollar aplicaciones web en las infraestructuras de Amazon era la falta de un balanceador de carga que presentara afinidad de servidores. Ésto representaba un problema muy grave para la creación de aplicaciones ya que, hoy en dia, se almacenan datos en variables de sesión para facilitar la navegación de los usuarios. Con un servidor único para la aplicación no existe tal problema porqué las variables de sesión siempre están disponibles, pero con diferentes servidores y un balanceador de carga se corre el riesgo de que diferentes peticiones de páginas web se sirvan desde diferentes servidores y las preferencias de los usuarios se pierdan.
Antes, Amazon tenía un balanceador de carga que derivaba las peticiones a diferentes servidores pero no servía para aplicaciones complejas, ya que no se podía configurar para que enviara todas las peticiones de un mismo cliente (navegador web) a un mismo servidor.
A través del blog de Amazon AWS se acaba de anunciar la disponiblidad de la afinidad de servidores en su balanceador de carga Elastic Load Balancer. Esta funcionalidad puede solucionar el problema que comentábamos al principio y facilitar la puesta en marcha de muchas aplicaciones en un entorno de altas prestaciones. Sin duda se trata de una gran notícia para muchos desarrolladores!!
Se puede consultar el post original de Amazon AWS aquí y la documentación aquí.
Mostrar una página en WordPress con todos los tags
Posted by Xavi in Blog, Programación Web on 06/04/2010
Con la migración del blog he tenido la oportunidad de reorganizar los plugins que utilizo en WordPress. Siempre me ha gustado intentar exprimir al máximo las posibilidades del software que utilizo y evitar el uso de plugins que hicieran funciones presentes en la base del mismo y eso es lo que he conseguido con la nube de tags.
Cuando empecé este blog mi experiencia con WordPress aun era muy limitada (usuario medio por decirlo de alguna manera) y instalé un plugin para mostrar una nube con todos los tags que había utilizado hasta el momento (Better Tag Cloud). Pues bien, el blog ha llegado a recopilar un número de etiquetas que no caben en un ‘tag cloud’ en la sidebar de este blog -si que caben pero ocupan demasiado- y me he decidido a abrir una página con todos los tags que se han asignado a los apuntes aquí almacenados.
Para publicar esta página lo primero que he pensado ha sido instalar otro plugin. Pero Naaah… WRONG ANSWER!!! WordPress tiene la potencia suficiente para poder hacer esto de una forma elegante y eficiente. A continuación explicamos los pasos que vamos a dar para mostrar dicha página:
- Crear un template nuevo para la página.
- Poner el código que nos va a mostrar la nube de tags.
- Crear la página y definir el template para que nos muestre la información.
NOTA: Yo utilizo el tema para WordPress Fusion 3.1. Así que todo el código que muestre estará relacionado con dicho tema. Adaptar el código de este tema a otro no debería ser muy costoso si se trata de un tema que sigue las directrices de WP para la creación de temas.

Crear un template nuevo para la página
Para crear un nuevo template debemos crear un archivo PHP con un nombre que defina lo que vamos a hacer con él (por ejemplo: tagcloud.php). En este archivo vamos a poner primero un comentario para que el motor del blog identifique el template de la página:
<?php /* Template Name: Tag Cloud */ ?>
Una vez creado dicho archivo lo podemos subir por FTP a la carpeta del tema (/wp-content/themes/fusion en mi caso).
Código de la página
Una vez subido el archivo (y otorgados permisos de escritura para que se pueda editar desde el editor de WordPress) ya podemos poner el código que queremos que se muestre en las páginas que se publiquen con esta plantilla. La apariencia que yo quiero que tenga esta página es la misma que la de la página principal pero sólo con la nube de tags. Para esto cogeremos el código de page.php, copiaremos la estrucura y la pegaremos en el archivo quitando el contenido del div con id “mid-content” (dónde se publica la lista de post en la página principal).
Una vez hecho esto, pondremos un título para la página (h3 para el tema Fusion) y pegaremos el código para mostrar la nube de tags:
<?php wp_tag_cloud('smallest=10&largest=26&number=0'); ?>
La apariencia final del archivo tagcloud.php debe ser parecido a este:
<?php /* Template Name: Tag Cloud */ ?>
<?php get_header(); ?>
<! -- mid content -->
<div id="mid-content">
<h3 class="title">Todos los tags de mis artículos</h3>
< ?php wp_tag_cloud('smallest=10&largest=26&number=0'); ?>
</div>
<! -- mid content -->
</div>
<! -- /mid -->
<?php get_sidebar(); ?>
<?php get_footer(); ?>
Crear la página
Para crear la página debemos ir a la sección de WordPress encargada de esta acción y crear una. Definimos el título y no introducimos nada más. En lugar de poner texto vamos a ir a la barra lateral y vamos a escoger el Template (o plantilla, depende del idioma en que tengamos instalado el sistema) Tag Cloud (o lo que hayamos escrito después de Template Name en el comentario inicial del archivo tagcloud.php.
Publicamos i… Listo!!!
Espero que os ayude
Programar con Flex Builder en una Ubuntu de 64 bits
Posted by Xavi in Linux, Programación Web on 15/02/2010
Adobe no tiene una versión estable de su IDE Flex Builder para Linux pero si existe una versión Alpha (bastante estable) de su plugin para Eclipse. Los puntos más negativos de este plugin son los siguientes:
- No permite la edición visual de los archivos MXML (ni la previsualización).
- Sólo se ejecuta con la versión 3.2 de Eclipse (Europa) y para una máquina virtual de java de 32 bits.
El primero de los puntos no se puede solucionar de ninguna de las maneras hasta que Adobe se ponga las pilas con la versión del IDE para Linux. El segundo de los puntos sí que se puede “arreglar” si estamos trabajando en una distribución de 64 bits (en nuestro caso para Ubuntu 9.10); en el siguiente artículo voy a describir el proceso que he seguido para poder programar en Flex con el plugin de Adobe en la versión 9.10 de Ubuntu (64 bits).

NOTA: El equipo donde he probado esta instalación ya tenia otras instalaciones de Java y librerías para compatibilizar software de 32 y 64 bits. Por este motivo no puedo asegurar que sólo siguiendo la instrucciones que vienen a continuación funcione todo correctamente.
Requisitos iniciales
Para poder realizar todo el proceso debemos descargar la versión 6 de Java (sobretodo de Sun) para Linux y la útlima Alpha para Linux del plugin de Eclipse de Adobe.
- Sun Java JDK 6:
Aquí. Descargar la versión para Linux (no Linux 64) y .bin (no .rpm.bin) - Adobe Flex Eclipse plugin:
Aquí.
Una vez descargados se deben dar permisos de ejecución al instalador del plugin de Flex. Por ejemplo:
chmod +x ./flexbuilder_linux_install_a5_112409.bin
Otro requisito esencial para la instalación es tener el plugin de Flash en el sistema (versión 9 o superior) y Eclipse Europa en un directorio sobre el que tengamos permisos para “cacharrear”.
Instalar el JDK de 32 bits
Para instalar el JDK de 32 bits primero tenemos que instalar el paquete java-package:
sudo apt-get install java-package
Y generar el archivo desde el binario de java:
DEB_BUILD_GNU_TYPE=i686-linux-gnu DEB_BUILD_ARCH=i386 fakeroot make-jpkg jdk-6u18-linux-i586.bin
NOTA: Esta instrucción se debe ejecutar como un usuario sin permisos y es un sólo comando(!). En caso de ejecutarse como root falla.
NOTA 2: El archivo resultante de este comando llevará el postfijo amd64 pero esto no quiere decir que sea una máqunia virtual de Java de 64 bits, sigue siendo el JDK de 32 que hemos bajado de la página de Sun.
Una vez ejecutados estos pasos debemos instalar el paquete DEB generado mediante GDebi o con el comando dpkg -i nombre de comando. En mi caso el comando completo era el siguiente:
dpkg -i sun-j2sdk1.6_1.6.0+update18_amd64.deb
NOTA: El proceso de instalación puede resultar fallido pero seguramente el JDK estará instalado correctamente.
Instalar Flex Plugin para Eclipse
Una vez instalado el JDK podemos ejecutar correctamente el instalador de Flex. Este nos preguntará por algunos datos referentes a la instalación y, en los últimos pasos, es posible que nos diga que no tenemos la versión 9 de Flash instalada en el sistema.
Si anteriormente hemos instalado el plugin de Flash para Firefox es posible que se trate de una versión posterior y no la detecte; en ese caso aceptaremos el mensaje de alerta y seguiremos adelante (sino seguimos adelante igualmente y lo instalamos posteriormente desde los repositorios).
Restaurar la versión de Java por defecto y otros pequeños ajustes
Una vez se ha realizado la instalación tendremos la máquina virtual de Java de 32 bits como versión de Java por defecto. Para cambiar esto debemos utilizar el comando alternatives:
sudo alternatives –config java
Seguimos los pasos que se indican en la consola y ya tendremos restaurada la versión de Java que utilizábamos por defecto antes de la instalación de la de 32 bits.
Para arrancar Eclipse con el plugin ya no podremos hacer doble click sobre el ejecutable de nombre eclipse sino que tendremos que hacer un pequeño script (yo lo he llamado flex.sh). Este script corrige el problema de los botones de Eclipse en Ubuntu 9.10 y especificarà con que Java se ejecutará el IDE. A continuación muestro el contenido de mi flex.sh:
#!/bin/sh
export GDK_NATIVE_WINDOWS=1
/usr/lib/j2sdk1.6-sun/bin/java -jar /home/usuario/eclipse/startup_fb.jar
Evidentemente los PATHS pueden cambiar dependiendo de la configuración de la máquina, del directorio donde se haya instalado el Eclipse, etc.
Una vez creado flex.sh y con este contenido le tenemos que dar permisos de ejecución:
chmod +x flex.sh
Y ejecutarlo!!!
Espero que este proceso pueda ayudar en su totalidad o parcialmente ya que se tocan muchos puntos
Modificar la cantidad de memoria disponible para Tomcat
Posted by Xavi in Linux, Programación Web on 14/12/2009
El rendimiento por defecto de un servidor Tomcat 6 es, normalmente, bastante bajo. Hace un par de días estaba realiando unas operaciones de recuperación de una aplicación en la que estamos trabajando y el servidor tardó varias horas en finalizar unas operaciones bastante básicas. Normalmente estas operaciones, al tomar tanto tiempo, se dan por perdidas en algún tipo de “deadlock” y se abortan (a no ser que se tenga el conocimiento de que van a durar tanto); pero a mi se me quedó la aplicación abierta en segundo plano (lo se… soy un desastre) y al final terminó las operaciones.
Al observar este comportamiento, recordé que había unos parámetros de configuración del Tomcat que modificaban el tamaño inicial y máximo de la pila de Java para un proceso y me puse a rebuscar entre las configuraciones de los diversos servidores con Tomcat a los que tenía acceso para recuperar esta pequeña “customización”.
Para modificar el tamaño inicial y máximo de la pila de Java para Tomcat (6) debemos modificar el archivo catalina.sh dentro del directorio bin en la raíz del directorio que contiene la instalación del Tomcat. La línea para añadir es la siguiente:
JAVA_OPTS="$JAVA_OPTS -Xms64M -Xmx1024M"
NOTA: Es importante que esta línea se añada furea de cualquier IF-ELSE del documento. Yo siempre lo añado justo antes de una línea comentada que pone Execute The Requested Command entre guiones, pero esto ya es a gusto del consumidor
El número que va después de -Xms es el tamaño inicial de la pila y el que va después de -Xmx es el tamaño máximo de ésta. La “M” sólo es para indicar que las dimensiones se están dando en MegaBytes. Dependiendo de los recursos de los que goza la máquina dónde tengamos el Tomcat estos parámetros deberán cambiar pero, por norma general, seguro que conseguimos una mejora en el rendimiento de nuestro servidor de aplicaciones Java.
Problemas con Eclipse en Ubuntu 9.10
Posted by Xavi in Linux, Programación Web on 11/12/2009
Si se trabaja con Eclipse, sea cual sea el lenguaje de programación que utilicemos, con el salto a Ubuntu 9.10 nos podemos encontrar que algunos botones dejan de funcionar correctamente.
Tanto con Eclipse como con otro software para Java (como Tomcat por ejemplo) soy partidario de descargar la versión adecuada del sitio web oficial. No es que no encuentre útil los paquetes .deb de los repositorios (para mi representan el 99% o más del software que tengo instalado en mi Ubuntu), sino que el software relacionado con Java me gusta tenerlo lo más “empaquetado” posible y conocer perfectamente dónde se han situado los archivos de configuración de dichos programas (a veces con el uso de apt-get perdemos un poco el control de dónde se encuentran algunos archivos de configuración).
Pues bien, como decía al principio de este apunte, con el paso a Ubuntu 9.10 he sufrido algún problema con muchas de las versiones de Eclipse (3.2, 3.4 y 3.5). El problema reside en que el programa parece no responder a según que botones. Para resolver este problema debemos crear un script (p.e: eclipse.sh) y poner los siguientes comandos:
#!/bin/sh
export GDK_NATIVE_WINDOWS=1
/path/a/eclipse/eclipse
Sustituyendo /path/a/eclipse/eclipse por la ruta donde se encuentra el archivo ejecutable de eclipse. Para arrancar damos permisos de ejecución a dicho archivo:
sudo chmod +x eclipse.sh
Y ejecutamos Eclipse desde consola o desde Nautilus con este script (siempre).
Con esto solucionaremos los problemas de los botones de Eclipse en Ubuntu 9.10

Amazon RDS – La nube de datos relacional*
Posted by Xavi in Bases de datos, Programación Web on 03/11/2009
Hace tiempo que trabajábamos buscando soluciones al problema de migrar aplicaciones que utilizan una base de datos relacional “clásica” a un entorno de cloud computing (más concretamente a Amazon EC2). Este problema nos llevó a interesantes estudios sobre el clúster y la replicación master-slave de MySQL hasta encontrar una solución bastante aceptable con esta última. Y después de todo este trabajo… va Amazon y lo resuelve con un nuevo servicio llamado Amazon RDS (Relational Database Service).
En pocas palabras, RDS viene a ser una puerta de acceso a una base de datos MySQL Server (de momento la versión 5.1 con InnoDB como motor principal) que corre encima de los servidores de Amazon Web Services. Amazon te proporciona una interfaz idéntica a la que utilizarías con un servidor dedicado a la base de datos pero no preguntes como funciona por debajo, no te preocupes por las actualizaciones de seguridad, no intentes acceder como si fuera un servidor normal y corriente… sólo utilízalo y disfrútalo!
Amazon RDS viene a completar la oferta de sistemas de bases de datos con SimpleDB (una base de datos muy simple para aplicaciones con una baja complejidad de datos) y Amazon EC2 Relational Database AMIs (una selección de AMIs con diferentes software de bases de datos preeinstalados).
Para interactuar con Amazon RDS, como con casi todos los servicios de AWS, tenemos la posibilidad de realizar llamadas a la API directamente o descargarnos las herramientas por linea de comandos (en mi opinión la mejor opción).
Para instalar las herramientas por linea de comandos podemos seguir los siguientes pasos:
- Descargamos las RDS Command Line Tools de la página oficial de Amazon
- Seteamos las variables JAVA_HOME y AWS_RDS_HOME necesarias en /etc/enviroment. Las linias que tendríamos que añadir son las siguientes
AWS_RDS_HOME="/path/a/la/carpeta/commandlinetools"
JAVA_HOME="/path/a/java"
En mi caso el “/path/a/java” es “/usr/lib/jvm/java-6-sun/” y si utilizas Ubuntu no creo que sea muy diferente
- El siguiente paso es añadir en el PATH del sistema el directorio /bin de las herramientas que hemos descargado. Para hacer esto, dentro del mismo archivo /etc/enviroment, añadiremos :$AWS_RDS_HOME/bin antes de las dobles comillas que cierran la expressión PATH=”blabla:/blabla:/blabla” para que quede de la forma PATH=”blabla:/blabla:/blabla:$AWS_RDS_HOME/bin”.
- Lo siguiente es abrir el archivo credential-file-path.template que encontraremos en la raíz del directorio de las herramientas y introducir nuestros datos de acceso a la cuenta de AWS.
- Una vez introducidas nuestras credenciales añadiremos la situación de este archivo en /etc/enviroment también:
AWS_CREDENTIAL_FILE="/path/a/credential-file-path.template"
Si queremos podemos modificar el nombre del fichero y moverlo a la localización que más nos guste, mientras mantengamos la informatcion de /etc/enviroment actualizada. - Una vez tengamos todo ésto solo queda reiniciar el ordenador para cargar todas estas variables y ya estaremos listos para empezar a jugar con Amazon RDS!
Me gustaría descubrir un método para recargar las variables de /etc/enviroment en caliente pero de momento los métodos que he encontrado no han acabado de funcionar correctamente, si tienes alguna sugerencia déjala en los comentarios
Bueno ahora viene la mala noticia… Amazon RDS de momento solo está disponible para Estados Unidos… Pero prometen tenerlo disponible para Europa en los próximos meses, veremos que tardan.
Os dejo un post del blog de Amazon Web Services en el que se introduce Amazon RDS enlace.
*No me agredais física ni intelectualmente por el juego de palabras!!
Tomcat 6 en Ubuntu
Posted by Xavi in Linux, Programación Web on 03/11/2009
Este es un post corto para poner de manifiesto un opinión basada en la experiencia profesional que he recogido trabajando con este servidor de aplicaciones y Ubuntu (versiones 9.04 y 9.10)

Cuando trabajeis con Tomcat 6 bajo Ubuntu, seguid estos pasos:
- Eliminad TODO rastro de OpenJDK
- Instalad el paquete de Java de Sun (sun-java6-jdk en mi caso)
- Descargad el Core de la página oficial de Tomcat
- Descomprimid el paquete y ubicad los archivos en la carpeta /usr/share/tomcat6
Siguiendo estos pasos en lugar del facílisimo “sudo apt-get install tomcat6″ tendremos una instalación de Tomcat completamente “compacta”. En el momento que deseáramos llevarnos esta instalación de Tomcat a otra máquina sólo necesitaríamos copiar los archivos y comprovar que en la máquina destino tenemos una versión compatible de Java.
Para arrancar el servidor tendremos que ejecutar como root ‘startup.sh’ en el directorio ‘/usr/share/tomcat6/bin/’ y para pararlo ‘shutdown.sh’ en el mismo directorio.
Disfrutad de vuestro Tomcat 6
Subir vídeos a YouTube con Zend Gdata
Posted by Xavi in Programación Web, Redes sociales on 24/08/2009
Aunque no sea difícil seguir los tres artículos relacionados con la subida de vídeos a You Tube (se encuentran todos a continuación) os dejo la referencia a los tres apuntes:
Y algunos enlaces de interés:
Subir vídeos a YouTube con Zend Gdata – Subir el vídeo
Posted by Xavi in Programación Web, Redes sociales on 24/08/2009
Para finalizar la serie de artículos dedicados a la subida de un vídeo a YouTube desde nuestra aplicación web en PHP (con el módulo Zend_Gdata) vamos a describir el proceso que se debe seguir desde el punto en que lo dejamos en el post anterior.
Una vez recibido el token de YouTube (ver post anterior) deberemos seguir estos pasos:
Upgrade del token recibido a un token de sesión
Para realizar más de una operación con la cuenta del usuario que se ha identificado en la página de YouTube debemos hacer un “upgrade” del token recibido. Para realizar una sola operación no sería necesario hacer este paso pero aquí recomendamos hacerlo para que no surjan problemas a posteriori con la identificación del usuario.
El upgrade del token requiere haber recogido el valor original de token enviado por YouTube a través de la petición. En el siguiente fragmento de código vamos a explicar cómo hacer la actualización del token recibido por un token de sesión presuponiendo que recuperamos el valor del token por GET.
$originalToken = $_GET['token'];
$ytClient = new Zend_Gdata_HttpClient();
$ytClient->setHeaders("X-GData-Key: key=VALOR_DE_TU_CLAVE_DE_DESARROLLADOR");
$ytClient->setAuthSubPrivateKeyFile('/path/a/clave.pem',null, true);
$sessionToken = Zend_Gdata_AuthSub::getAuthSubSessionToken(trim($originalToken),$ytClient);
$ytClient->setAuthSubToken($sessionToken);
En este fragmento de código podemos observar como recuperamos el valor del token por GET y cómo construimos el Zend_Gdata_HttpClient para que la petición de actualizar el token pueda ser satisfecha. En la última instrucción de este fragmento se setea el nuevo token de sesión en el cliente http para que las peticiones posteriores sean ejecutadas con los permisos que se han conseguido con la identificación de este usuario.
La clave de desarrollador y la clave.pem que se utilizan en este trozo de código corresponden a los requisitos previos que comentábamos en el primer post sobre la subida a vídeos a YouTube. Estas claves se incluyen en el cliente http que realizará las consultas a modo de signatura (para la seguridad de las peticiones que se realizarán a YouTube).
Subir el vídeo
Llegados a este punto, la subida del vídeo es la parte más sencilla de todo el proceso. Sólo hace falta seguir al pie de la letra las indicaciones existentes tanto en la documentación del Zend Framework como en la página de la API de YouTube destinada a este propósito para que la operación llegue a buen puerto.
A continuación se detalla el código necesario para la inserción del video a YouTube:
$yt = new Zend_Gdata_YouTube($ytClient);
$myVideoEntry = new Zend_Gdata_YouTube_VideoEntry();
$filesource = new Zend_Gdata_App_MediaFileSource('Sample.mov');
$filesource->setContentType('video/quicktime');
$filesource->setSlug('Sample.mov');
$myVideoEntry->setMediaSource($filesource);
$myVideoEntry->setVideoTitle('Prueba de subida a YT');
$myVideoEntry->setVideoDescription('Una descripción');
$myVideoEntry->setVideoCategory('Music'); //La categoría debe ser una categoría válida en YouTube
$myVideoEntry->SetVideoTags('mytest, sample'); //Tags
$myVideoEntry->setVideoDeveloperTags(array('solutions', 'iceberg')); //Tags como desarrollador
//URI estática para realizar las subidas
$uploadUrl = 'http://uploads.gdata.youtube.com/feeds/api/users/default/uploads';
//Bloque try-catch para subir el vídeo
try {
$newEntry = $yt->insertEntry($myVideoEntry, $uploadUrl, 'Zend_Gdata_YouTube_VideoEntry');
} catch (Zend_Gdata_App_HttpException $httpException) {
echo $httpException->getRawResponseBody();
} catch (Zend_Gdata_App_Exception $e) {
echo $e->getMessage();
}
De forma opcional se puede geolocalizar el vídeo que se está subiendo pero esto se puede encontrar de forma sencilla en la documentación de la API de YouTube.
A modo de epílogo sólo comentar que el archivo de vídeo que se utiliza ‘Sample.mov’ debe estar alojado de forma obligatoria en el servidor desde el que se está ejecutando esta operación. YouTube no acepta URLs como input para la subida de vídeos (lo hemos probado con unos enlaces públicos a archivos alojados en Amazon S3 y no ha habido manera).
Espero que toda la información vertida en estos tres artículos haya sido de utilidad, en breve se publicará un meta-post con los enlaces a los tres apuntes relacionados.
Subir vídeos a YouTube con Zend Gdata – Identificación del usuario
Posted by Xavi in Programación Web, Redes sociales on 21/08/2009
Siguiendo el post anterior, dónde podíamos ver que recursos nos hacían falta para empezar la odisea de compartir un vídeo en YouTube directamente, vamos a explicar el procedimiento para identificar un usuario en YouTube desde nuestra aplicación web.
Existen tres alternativas para identificar los usuarios en sus cuentas de YouTube desde aplicaciones externas:
- La primera se basa en el protocolo OAuth, pero aunque sea muy interesante, el soporte que tiene el módulo Zend_Gdata para este tipo de identificación es bastante limitado (recordamos que estamos trabajando sobre la versión 1.8.4).
- La segunda se llama ClientLogin y aunque su utilización parezca mucho más sencilla que las otras dos alternativas Google/YouTube sólo aconseja implementar este proceso de autenticación en aplicaciones de escritorio (y nunca implementarlo en aplicaciones web).
- La tercera, y como habréis podido adivinar leyendo la descripción de las dos anteriores la que vamos a implementar aquí, recibe el nombre de AuthSub y se basa en que el usuario se identifica en la página original de YouTube y YouTube manda al servidor de nuestra aplicación de forma segura los datos de conexión de dicho usuario.
Después de esta pequeña introducción vamos a explicar los pasos para identificar un usuario en YouTube mediante el protocolo AuthSub con el módulo Zend_Gdata.
Identificar un usuario en YouTube con AuthSub
Para identificar un usuario mediante este protocolo el primer paso de todos es direccionar al usuario a una página de YouTube para que este se identifique y de permiso para que nuestra aplicación acceda a su cuenta de usuario. Para saber a que URL debemos direccionar al usuario debemos correr el siguiente codigo PHP:
<?php
$nextUrl = 'http://nombredominio.com/path/a/pagina/de/subida';
$scope = 'http://gdata.youtube.com';
$secure = true;
$session = true;
$authSubUrl = Zend_Gdata_AuthSub::getAuthSubTokenUri($nextUrl, $scope, $secure, $session);
?>
El contenido final de $authSubUrl es la URL de YouTube dónde tenemos que redireccionar al usuario (siempre que tengamos en regal todos los requisitos previos que comentamos en el post anterior). Aun así vamos a explicar para que se utilizan las cuatro variables que hemos definido antes de generar esta dirección.
- $nextUrl:
$nextUrl nos indica a que página de nuestra aplicación queremos que YouTube redireccione al usuario después de haber finalizado la identificación en su aplicación. Este parámetro acepta variables en la URL por GET, así ‘http://nombredominio.com/path/a/pagina/de/subida’ podría ser perfectamente ‘http://nombredominio.com/path/a/pagina/de/subida?video=idedelvideo’.
- $scope:
$scope es la variable que indica al método getAuthSubTokenUri en que servicio queremos identificar el usuario (del mismo modo que identificamos en YouTube podemos identificar usuarios en Picasa, Calendar u otros servicios de Google cambiando el $scope).
- $secure:
$secure indica si el tipo de identificación que estamos pidiendo a YouTube es para acceder sólo a datos públicos (requerimientos de seguridad menores) o también para modificar los contenidos del usuario (requerimientos de seguridad mayores).
- $session:
$session define si la identificación que nos proveerá YouTube podrá ‘upgradearse’ para utilizarse durante una sesión (navegador) o sólo para una operación. Para hacer un upload de un vídeo es posible que no fuese necesario hacer este upgrade pero igualmente lo vamos a explicar en el siguiente post.
Para que el direccionamiento del usuario a YouTube sea exitoso es necesario añadir la clave de desarrollador (ver post anterior) ya sea en la URL por GET o en el header de la petición (dependiendo de como vayas a llevar al usuario a esa dirección). Veamos como añadiríamos la clave de desarrollador de las dos formas:
Añadir la clave de desarrollador en la petición a YouTube
- Por GET en la URL:
Para añadir la clave del desarrollador en la URL como parámetro GET debemos concatenar su valor a continuación de $authSubUrl:
$authSubUrl = $authSubUrl.'&key=VALOR_DE_TU_CLAVE_DE_DESARROLLADOR'; - Añadiendo la clave en el header:
Podemos añadir la clave de desarrollador en el header de la petición para que quede de la siguiente forma:
X-GData-Key: key=VALOR_DE_TU_CLAVE_DE_DESARROLLADORPara realizar esto desde de PHP podemos executar la siguiente operación:
header("X-GData-Key: key=".YOUTUBE_API_KEY);
Si todo ha funcionado como es debido el usuario ya debe haber accedido a su cuenta en YouTube y debe haber dado permiso para que nuestra aplicación web realice las operaciones pertinentes en sus contenidos. En este caso nos debe haber llegado una petición a nuestro servidor, más concretamente una petición a la página ‘http://nombredominio.com/path/a/pagina/de/subida’.
En la petición “de vuelta” de YouTube nos vamos a encontrar que por GET vamos a recibir el valor de una variable llamada token. Token es el nombre de la variable que YouTube utiliza para certificar la identificación de un usuario concreto. Esta variable nos será imprescindible para poder firmar las peticiones que de aquí en adelante vamos a enviar a YouTube.
En el próximo y último post sobre Subir vídeos a YouTube con Zend Gdata vamos a describir que operaciones debemos llevar a cabo cuando YouTube nos garantiza el acceso a la cuenta de un usuario mediante el token. Hasta pronto!


Comentarios recientes