Posts Tagged Zend Framework
Breves vacacionales
Posted by Xavi in Bases de datos, Linux, Programación Web on 20/09/2009
Desde la tranquilidad de unas vacaciones merecidas no me han pasado por alto algunas noticias como las siguientes:
- MySQL Workbench 5.2 ha llegado a su versión Alpha 3: Nuestra herramienta preferida para ayudar en el diseño de bases de datos da un paso más hacia su versión final. Aquí el post original del equipo de desarrollo del programa.
- Cahaya CMS publica su primera versión estable: Cahaya és un CMS basado en el Zend Framework. Aunque sea un proyecto un poco verde, resulta muy interesante ya que un equipo con conocimientos del Zend Framework no debería aprender un nuevo framework (cosa que sí que pasa con Joomla o Drupal). Aquí el post original de la Zend Developer Zone.
- Gloobus el Quick Look para Gnome: Quick Look aporta una magnifica experiencia de usuario a los usuarios de Mac. La posibilidad de previsualizar el contenido de un archivo de forma casi inmediata representa un gran aumento de productividad que no pasa por alto a los usuarios de Mac OS; ahora Gloobus quiere portar esta funcionalidad a Gnome. Aquí os dejo el post de VivaLinux que me ha informado sobre tal proyecto.
Són unas explicaciones breves a la espera de volver a la actividad y entrar en profundidad en cada uno de los temas
Disfrutad del trabajo, que dignifica!
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!
Subir vídeos a YouTube con Zend Gdata – Requisitos previos
Posted by Xavi in Programación Web, Redes sociales on 19/08/2009
Hace unas semanas que el equipo de Iceberg se centró en la integración de YouTube y otros servicios de Google en los proyectos en los que trabajamos. Integrar los servicios de Google dentro de las aplicaciones que podamos ofrecer en un futuro cercano representa un salto cualitativo que queríamos dar pero que no sabíamos si tendríamos los recursos necesarios para hacer realidad.
El proceso para realizar una integración de este tipo no es sencillo pero tampoco es tan complicado como puede parecer cuando los errores se multiplican y no se avanza. El mayor ‘handicap’ con el que nos hemos encontrado es la falta de cohesión de la documentación que ofrece Google y el Zend Framework (la integración de estos servicios se ha realizado en aplicaciones web PHP que utilizan Zend Framework como motor principal de la aplicación, más concretamente la versión 1.8.4). Por culpa de esta falta de cohesión, la dedicación a esta tarea ha aumentado más de lo que seria deseable.
Este post pretende ser el primero de una serie de apuntes que detallen paso a paso cual es el camino a seguir para llegar a subir vídeos a YouTube desde nuestra propia aplicación (gracias a mi compañera Laura por meter presión para publicarlos!). El primero de la serie viene dedicado a que requisitos debemos cumplir para poder empezar a pensar en una integración similar.
Requisitos previos
- Debemos tener un servidor de desarrollo accesible desde Internet (con un dominio o sub-dominio propio):
La identificación de usuarios de nuestra aplicación web en los servicios de Google es el punto más crítico en el proceso de compartir un vídeo en YouTube. Para aplicaciones web, Google/YouTube utiliza un protocolo que incluye redirecciones a páginas que deben ser accesibles desde su sistema. Por este motivo debemos tener un servidor ‘visible’ a nuestra disposición.
- Utilizar Zend Framework como motor de la aplicación o tener funcionando el módulo Zend_Gdata:
El Zend Framework tiene integrado el módulo Zend_Gdata pero este último se puede descargar por separado si no estamos trabajando con dicho framework para desarrollar nuestra aplicación (¿Te has preguntado porqué no lo estás utilizando
?). La documentación sobre como poner en marcha una aplicación con este framework es muy extensa así que si estáis interesados podéis visitar la guía de referencia o la QuickStart en la página oficial.Si sólo estáis interesados en poner en funcionamiento el módulo Zend_Gdata os aconsejo que visitéis la página de la API de YouTube destinada a eso. Con este recurso y la documentación que hay dentro de la descarga de módulo Zend_Gdata no deberíais tener más problema.
- Conseguir una clave de desarrollador:
Para conseguir una clave de desarrollador en Google sólo hace falta tener una cuenta de Google (si utilizas cualquiera de sus servicios ya tienes una) y acceder al “dashboard” de la API de YouTube.
Piensa que esta clave de desarrollador después también te servirá como clave para otros servicios como Picasa Albums o Calendar.
- Registrar el dominio dónde vas a ejecutar la aplicación en Google:
Google necesita que registres el dominio en su sistema para permitir que realices operaciones que modifiquen los contenidos que los usuarios tienen en sus cuentas (por ejemplo subir un vídeo a su cuenta de YouTube). En este proceso se tiene que registrar el dominio en la página de gestión de dominiosde Google (con una cuenta de usuario de Google, puede ser la misma que la que hemos utilizado en el paso anterior).
El registro de un dominio como seguro para Google cuenta con varios pasos. Primero debemos introducir el dominio y paso seguido nos pedirá que verifiquemos que somos los propietarios o administradores de ese dominio. Para verificar un dominio tenemos que entrar en el enlace que pone ‘Manage nombredominio.com’ y escoger uno de los métodos que se nos ofrece.
NOTA: Aunque se recomiende el método de añadir un meta-tag yo he seguido el método de subir un archivo html y no he tenido ningún problema, la verificación ha sido inmediata.
Una vez verificado el archivo aceptamos los términos del servicio (si estamos de acuerdo con ellos) y nos encontraremos un formulario con los campos siguientes:
- Target URL path prefix:
Aquí debes poner “http://nombredominio.com” si quieres que tu aplicación pueda hacer peticiones de identificación desde diferentes páginas (de momento nosotros lo hemos definido así y gestionamos la identificación de los usuarios en diferentes servicios desde diferentes páginas, pero esto es casi cuestión de gustos y cada uno tendrá el suyo)
- Domain description:
Este campo es opcional, se trata de una breve descripción sobre el dominio.
- Upload X.509 cert:
Este paso es un poco más complicado que el resto. Se trata de subir un certificado de seguridad que Google utilizará para asegurarse que las peticiones que mandamos son seguras. Como no soy un experto en estos temas sólo señalar que lo que tenemos que subir es el certificado y no la clave privada. Para generar una clave privada y un certificado auto-firmado podéis entrar en el siguiente enlace de AOL sobre como generar certificado auto-firmados
Una vez tengamos completado el formulario en la cabecera del formulario deberá aparecer la palabra “Active” en verde al lado del nombre del dominio. En este momento estamos listos para empezar a programar.
- Target URL path prefix:
La primera operación que deberemos realizar después de preparar nuestro entorno con los pasos descritos anteriormente es la de identificar al usuario, pero eso vendrá en el siguiente post… Hasta que lo cuelgue espero que os sea de utilidad!
Autenticar un usuario en Zend Framework – Identificar usuario
Siguiendo el hilo del apunte anterior vamos a ver como identificar un usuario una vez programado el adaptador.
El componente Zend_Auth implemente el patrón Singleton de diseño. Esto quiere decir que en todo momento sólo tendremos una instancia de esta classe y que para obtenerla deberemos utilizar su método estático getInstance(). La instancia de Zend_Auth será la que utilizaremos para identificar al usuario una vez obtengamos sus datos.
Formulario para identificar
Para identificar un usuario, en nuestro caso, nos hace falta conocer su nombre de registro (nickname, mail o lo que se utilice) y su contraseña. Con un formulario estándar nos bastará:
<form action="/authentication/login" method="post">Podemos observar que el formulario apunta al controlador AuthenticationController y la acción loginAction. Aquí es dónde identificaremos el usuario.
<input type="text" name="username"/>
<input type="password" name="pwd"/>
</form>
Identificar el usuario en el controlador
Para identificar al usuario deberemos implemetar la acción loginAction dentro del controlador que se encargue de identificar a los usuarios (no tiene por qué ser AuthenticationController). Veamos un ejemplo:
<?phpA partir de aquí se puede diferenciar más el comportamiento del sistema en función del $res->getCode() por ejemplo. Un switch-case nos puede servir para diferenciar un error en el nombre de usuario o en la contraseña.
class RegisterController extends Zend_Controller_Action{
...
public function loginAction(){
require_once('/path/to/AuthenticationAdapter.php');
$auth = Zend_Auth::getInstance();
/* Comprovaciones de que $_POST['username'] y
* $_POST['pwd'] existen */
if(/* Existen y cumplen las restricciones*/){
$adapt = new AuthenticationAdapter($_POST['username'], $_POST['pwd']);
$res = $auth->authenticate($adapt);
if($res->getCode() == Zend_Auth_Result::SUCCESS){
/* Esta línea es muy importante porqué es la que nos grabará los datos que hemos
* introducido en la variable $sessionData (en el post anterior) en la session */
$auth->getStorage()->write($result->getIdentity());
}
}
}
Consultar si un usuario está identificado
Una vez identificado el usuario y guardados los datos que queremos (session) tendríamos que poder acceder a esta información desde cualquier punto del sistema. Esto se puede hacer a través del método hasIdentity() del componente Zend_Auth. Veamos un ejemplo de como lo utilizaríamos si quisiéramos redirigir a la página principal un usuario que no está identificado:
/* En alguna action que no queremos que los usuarios no identificados vean */Espero que a partir de aquí podais identificar vuestros propios usuarios
$auth = Zend_Auth::getInstance();
if($auth->hasIdentity()==true){
/* Si está identificado guardaremos los datos
* que pusimos en $sessionData en la variable $identity */
$identity = $auth->getIdentity();
}else{
/* Si no está identificado lo redirigimos al document root */
$this->_redirect('/');
}
Os dejo la dirección del manual de referencia del Zend Framework porqué, una vez llegados a este punto, las posibilidades que tenemos con Zend_Auth son enormes.
Si teneis alguna duda ya sabeis, comentad!
Autenticar un usuario en Zend Framework – Crear el adaptador
Posted by Xavi in Programación Web on 30/03/2009
Después de pelearnos nuestras horas con el framework de Zend hemos conseguido identificar un usuario con las herramientas que provee este framework (Zend_Auth). La adapatación no ha sido al 100% porqué teniendo la información relativa a los usuarios en una base de datos no utilizamos el adaptador que Zend tiene empleado para estos fines (Zend_Auth_Adapter_DbTable) sino que implementamos un adaptador desde cero.
Antes de empezar a definir que nos hace falta para poner en marcha la identificación de usuario comentamos que estos pasos se han realizado en un servidor Lighttpd-MySQL-PHP5 en un sistema operativo Ubuntu 8.10. Ahora sí, vamos a ver como establecer una autentificación de usuarios:
Implementar un adaptador para autentificar usuarios
Este paso se puede modificar según el origen de la información que vayamos a usar. El framework tiene soluciones específicas para datos de acceso almacenados en base de datos, provenientes de peticiones HTTP, de un servidor LDAP o por OpenID. Como hemos comentado al principio nuestros datos estan almacenados en una base de datos pero vamos a implementar un adaptador desde cero.
Para implementar un adaptador desde cero debemos implementar la interfície Zend_Auth_Adapter_Interface, para eso deberemos implementar obligatoriamente el metodo authenticate() (por razones derivadas de la herencia) y también le añadiremos un par de cositas más. Este adaptador debe recibir la información necesaria para identificar un usuario y realizar la comprovación.
Veamos un ejemplo de la classe:
<?php
class AuthenticationAdapter implements Zend_Auth_Adapter_Interface{
private $_username = null;
private $_password = null;
public function __construct($username, $password){
$this->_username = $username;
$this->_password = $password;
}
public function authenticate(){
//TODO comprobar si $username y $password estan presentes en la base de datos
...
if(/* Estan presentes*/){
/* $sessionData es una variable con la información que queremos guardar en sessión */
return new Zend_Auth_Result(Zend_Auth_Result::SUCCESS,$sessionData);
}else{
/* Si no esta el $username */
return new Zend_Auth_Result(Zend_Auth_Result::FAILURE_IDENTITY_NOT_FOUND,$sessionData);
/* Si el password es incorrecto */
return new Zend_Auth_Result(Zend_Auth_Result::FAILURE_CREDENTIAL_INVALID,$sessionData);
/* Error en la identificación por otros motivos */
return new Zend_Auth_Result(Zend_Auth_Result::FAILURE,$sessionData);
}
}
}
En el próximo post seguiremos con el controlador y como utilizar este adaptador. No falteis!
jQuery en Zend Framework sin la API Google
Posted by Xavi in Programación Web on 27/03/2009
El Framework de Zend ofrece la possibilidad de ampliar sus funcionalidades con las del framework de JavaScript jQuery (empezó con http://www.dojotoolkit.org/, pero la integración con jQuery ya está bastante avanzada).
El principal problema que podemos tener al empezar a utilizar estas nuevas características es que por defecto el framework carga los archivos .js de la API de Google. Esto puede ser beneficioso en algunos casos, pero si estamos acostumbrados a una versión determinada de jQuery (o de sus plugins para la interfaz de usuario como es jQuery-UI) quizás queremos cargarla nosotros mismos de nuestro servidor.
El método para determinar desde que ruta local queremos cargar los .js es el setLocalPath() (setUiLocalPath() para jQuery-UI) pero si no queremos realizar esta tarea para todas las acciones que programemos tenemos la siguiente alternativa.
ATENCIÓN: Esea método puede no ser el más correcto, puede que haya un sistema mucho más óptimo de realizar estos cambios, pero en nuestro caso no hemos encontrado un buen sistema centralizado para cambiar el origen de los archivos .js de la API de Google al servidor local.
Para garantizar que los archivos que se van a cargar de jQuery son los de nuestro servidor debemos tenerlos bien localizados. En nuestro caso estarán en la carpeta /js dentro de la carpeta /public (que es donde apunta el document root de nuestro servidor, original eh!?).
Una vez localizados sólo debemos encontrar el archivo Container.php dentro de la carpeta /library/ZendX/JQuery/View/Helper/JQuery i editarlo. Dónde nos encontremos esta línea:
protected $_jqueryLibraryPath = null;Debemos poner la ruta a nuestro archivo .js de jQuery:
protected $_jqueryLibraryPath = '/js/jquery-1.3.2.min.js';Si también vamos a utilizar la extensión UI debermos hacer lo mismo con la línea siguiente:
protected $_uiPath = null;La debemos cambiar por la de nuestro archivo .js de la UI:
protected $_uiPath = '/js/jquery-ui-1.7.1.custom.min.js';
Si sabeis un método mejor, adelante!
Lighttpd y la vida después de Apache
La programación de sitios web dinámicos en PHP va casi siempre asociada al servidor Apache pero, en ocasiones, se puede recurrir a alternativas para mejorar el rendimiento de las aplicaciones web. En el presente artículo explicaremos la instalación del servidor Lighttpd en un sistema Ubuntu 8.10 para proyectos en PHP (compatibles con el Zend Framework).

Lighttpd es un servidor web más ligero que Apache que aporta un plus de rendimiento muy conveniente en según que entornos. El primer paso que vamos a describir se debe realizar sólo en el caso de que tengamos instalado un Apache 2 en el servidor.
Eliminar Apache 2 del servidor
Para eliminar este servidor del equipo podemos recurrir a la linea de comandos o al gestor de paquetes Synaptic. Para la línea de comandos deberemos ejecutar la siguiente orden y aceptar que nos desinstale todas las dependencias:
sudo apt-get remove apache2.2-commonPara el gestor Synaptic tendremos que localizar el paquete apache2.2-common, marcarlo para eliminar y aplicar junto con las dependecias también.
NOTAS:
- Seguramente nos pedirá desinstalar el paquete php5 de las dos formas, pero no pasa nada, después ya volveremos a instalar el interprete para este lenguaje.
- Si desinstalamos el paquete apache2 realmente no estaremos eliminando el servidor porque se trata de un meta-paquete que puede ser eliminado sin ninguna repercusión para los paquetes asociados.
Instalar el servidor Lighttpd
Para instalar el servidor yo recomiendo usar la linea de comandos (si se deseara utilizar Synaptic se tendrían que instalar los mismos paquetes que vamos a instalar a través del terminal pero buscándolos uno a uno).
Los paquetes que vamos a instalar son lighttpd, php5-cgi y lighttpd-doc (siempre que queramos la documentación de soporte para el servidor, mi recomendación es instalarla, nunca está de más…); lighttpd y lighttpd-doc son paquetes del servidor web mientras que php5-cgi será el paquete para interpretar las páginas dinámicas en PHP. Veamos el comando para instalar estos paquetes a la vez:
sudo apt-get install lighttpd lighttpd-doc php5-cgiNOTAS:
- Después de este paso aún no podremos ejecutar páginas PHP, nos faltan unos pequeños pasos que veremos a continuación.
- Si nuestra aplicación en PHP requiere acceso a base de datos tendremos que instalar los paquetes correspondientes (php5-mysql, php5-odbc…), en el caso de que necessitáramos manipular imágenes, instalaremos otros paquetes como por ejemplo php5-gd. En resumen, php5-cgi sólo nos proporciona un interprete básico de archivos PHP, para extenderlo existen muchos paquetes pero no los vamos a tratar en este post.
- Si intentamos visualizar una página PHP al final de este paso es posible que el servidor nos devuelva un error 403 FORBIDDEN. Para solucionarlo sólo tienes que seguir leyendo…
Activar PHP en Lighttpd
PHP debe ser activado en el archivo principal de configuración del servidor Lighttpd. Este archivo se llama lighttpd.conf y se encuentra en /etc/lighttpd/ para editarlo con Gedit por ejemplo tenemos que ejecutar el siguiente comando en el terminal:
sudo gedit /etc/lighttpd/lighttpd.conf* si estamos sin un entorno gráfico podemos editarlo con vim, pico o nano.
En el archivo de configuración vamos a tener que añadir el módulo fast-cgi (mod_fastcgi) nos va a tener que quedar una sección parecida a esta:
server.modules = (i tenemos que añadir nosotros una nueva sección como la siguiente (la podemos introducir justo después del paréntesis para cerrar la sección anterior):
"mod_access",
"mod_alias",
"mod_accesslog",
"mod_compress",
"mod_rewrite",
"mod_redirect",
"mod_evhost",
"mod_fastcgi",
# "mod_usertrack",
# "mod_rrdtool",
# "mod_webdav",
# "mod_expire",
# "mod_flv_streaming",
# "mod_evasive"
)
fastcgi.server = ( ".php" => ((NOTAS:
"bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php.socket"
)))
- Si necessitamos reescribir las URLs de las peticiones al servidor nos tenemos que asegurar que no estén comentadas (sin el ‘#’ delante) las lineas “mod_rewrite” y “mod_redirect”.
- El path “/usr/bin/php-cgi” puede depender de la instalación de los paquetes de PHP. Para asegurarnos podemos ejecutar el comando ‘whereis php-cgi’ y comprovar que nos arroja la misma ruta que hemos escrito en el archivo de configuración.
- Se pueden encontrar más opciones de configuración del modulo de PHP en la página oficial del servidor web aquí.
Setear un servidor virtual en Lighttpd
Se pueden setear servidores virtuales en Lighttpd de forma muy simple modificando el mismo archivo de configuración que en el apartado anterior (/etc/lighttpd/lighttpd.conf). Para setear un servidor virtual con la dirección “direccionaleatoria.com” y directorio base “/home/user/proyecto” tendremos que añadir una sección al final del archivo de configuración como la siguiente:
$HTTP["host"] == "direccionaleatoria.com" {NOTAS:
server.document-root = "/home/user/proyecto/"
}
- Igual que con el módulo PHP, se pueden encontrar más opciones de configuración avanzada de servidores virtuales en la página oficial del proyecto Lighttpd aquí.
Definir reglas de reescritura de URLs para el Zend Framework
Lighttpd puede ejecutar de forma eficiente proyectos realizados bajo el framework PHP de Zend siempre que se definan correctamente las reglas de reescritura de las URLs. Para conseguir esto debemos añadir las siguientes lineas al archivo de configuración:
url.rewrite-once = (Podemos conseguir que esta reescritura sólo afecte a un servidor virtual si añadimos estas lineas dentro del apartado correspondiente. Si queremos que la reescritura sólo afecte al servidor virtual que hemos seteado en el paso anterior la sección del servidor virtual debería ser la siguiente:
".*\?(.*)$" => "/index.php?$1",
".*\.(js|ico|gif|jpg|png|css)$" => "$0",
"" => "/index.php"
)
$HTTP["host"] == "direccionaleatoria.com" {NOTAS:
server.document-root = "/home/user/proyecto/"
url.rewrite-once = (
".*\?(.*)$" => "/index.php?$1",
".*\.(js|ico|gif|jpg|png|css)$" => "$0",
"" => "/index.php"
)
}
- Estas normas de reescritura se pueden encontrar en los foros oficiales del Zend Framework aquí.
Y con estos breves pasos… muy breves!!! Ya tenemos una aplicación web PHP (con Zend Framework o no) corriendo bajo Lighttpd, provadlo y me contais si corre más que en Apache.

Comentarios recientes