Aquellos de vosotros que lleváis más tiempo visitando mi blog, os habréis dado cuenta de que he cambiado el software con el que gestiono mi galería de fotografías. Anteriormente usaba Gallery2 por su integración con WordPress mediante el plugin WPG2 (para el que desarrollé una mejora). Pero si bién era una solución válida, resultaba demasiado compleja. Era como matar moscas a cañonazos. Sólo necesitaba una mínima parte de las características de Gallery2.

Por eso, un día empecé a evaluar alternativas que se ajustaran mejor a mis necesidades. Las únicas características que me interesaban eran que pudiera organizar las fotografías en álbumes, que se pudiera mostrar los datos EXIF de las fotografías, poder etiquetarlas, valorarlas y comentarlas, que se integrara con WordPress y que fuera una herramienta libre. Finalmente encontré Zenphoto, que cumple con todas esas necesidades excepto la integración con WordPress. En su web lo definen como:

Zenphoto is an answer to lots of calls for an online gallery solution that just makes sense. After years of bloated software that does everything and your dishes, zenphoto just shows your photos, simply. It’s got all the functionality and “features” you need, and nothing you don’t. Where the old guys put in a bunch of modules and junk, we put a lot of thought. We hope you agree with our philosopy: simpler is better. Don’t get us wrong though –zenphoto really does have everything you need for your online gallery, and you’ll even stare in awe at some of the innovative innovations we innovated upon.

Con el plugin ZenphotoPress para WordPress conseguí poder añadir fotos de la galería en los posts de forma simple. Pero integrar la apariencia me lo tuve que currar yo, usando como guía este post de Steffen Rusitschka. Pero con ese método Google no indexaba las páginas de la galería, aunque se visualizaban correctamente, porque todas devolvían un status 404. Además, compartían el título (tag <title> del HTML) haciéndolo muy poco Search Engine Friendly. Para solucionarlo tuve que modificar un poco el código de Steffen. Este es el index.php de mi theme integrado con el WordPress:

<?php if (!defined('WEBPATH')) die(); normalizeColumns(3, 6); ?>
<?php require($_SERVER['DOCUMENT_ROOT'].'/wp-blog-header.php'); ?>
<?php
// set the HTTP status
status_header('200');
 
// add the zen headers to the wordpress header
function zentitle() {
  echo '&raquo; '.strip_tags(getGalleryTitle());
}
function addzen() {
  global $_zp_themeroot;
  echo '<link rel="stylesheet" type="text/css" media="screen, projection" href="'.$_zp_themeroot.'/css/master.css" />';
  zenJavascript();
  printRSSHeaderLink('Gallery','Gallery RSS');
}
add_action('wp_head', 'addzen');
add_action('wp_title', 'zentitle');
?>
<?php get_header(); ?>
 
<div class="index">
  <!-- Código original de Zenphoto -->
</div>
 
<?php get_footer(); ?>

Lo más extraño es que yo tengo las bases de datos del blog y de la galería separadas pero no he necesitado hacer lo que comenta Steffen de conectarnos a una base de datos y luego a la otra. Por eso, si comparáis mi trozo de códico con el de Steffen veréis que falta esa parte. Lo siguiente será integrar el login de las dos aplicaciones, para lo que he visto que hay plugins, pero de momento no lo he mirado.

Como las URL de los álbumes han cambiado, también he añadido reglas de redirección en el .htaccess para no perder los enlaces que pudiera haber desde otras páginas.

Al final he conseguido dejarlo bastante bien integrado y estoy muy contento, tanto del resultado como de la aplicación en sí. Tiene justo lo que necesito. Ni más, ni menos.

La aparición a mediados de 1998 de los VirtualHosts basados en nombre en la versión 1.3 del servidor web de Apache significó un cambio importante en el mundo de los servidores web ya que permitía configurar webs en diferentes dominios, todos ellos compartiendo la misma dirección IP. Tampoco hay que olvidar que esa mejora fue posible gracias a que los navegadores (por aquel entonces disponíamos de Netscape Communicator 4.5 e Internet Explorer 4.0 [1]) implementaron la versión 1.1 del protocolo HTTP, según la cual el navegador debe enviar el nombre del dominio al que se están conectando en la cabecera Host, usada por los servidores web para discriminar que a VirtualHost deben enviar la petición.

Desgraciadamente, las webs seguras nunca han podido beneficiarse de esta mejora por la forma en que funciona el protocolo HTTPS (HTTP sobre SSL). La cabecera Host que permite al servidor discernir el host virtual al que va dirigida la petición del usuario está a nivel HTTP, debajo del cual tenemos SSL y su negociación. En esa negociación es cuando el servidor envía al cliente su certificado X.509 y el navegador comprueba la validez del certificado comparando el campo CN del certificado con el nombre del dominio al que se está conectando. Por tanto, el servidor debe enviar el certificado correcto, y por tanto del host virtual correcto, al navegador antes que este le pueda indicar mediante la cabecera Host el dominio al que se quiere conectar. La única solución es usar VirtualHosts basados en dirección IP.

Sin embargo, si los diferentes dominios que tenemos en el servidor son subdominios que comparten el second-level domain, o SLD, podemos conseguir que todos ellos dispongan de web segura usando una única dirección IP. Por ejemplo www.example.com y mail.example.com tienen el SLD example.com en común.

Para conseguirlo, también es imprescindible el uso de un Wildcard SSL Certificate (he decidido no traducirlo porque ninguna de las tradicciones que se me han ocurrido me acababa de gustar), que es un certificado SSL en el que el nombre del dominio contiene un comodín. Por ejemplo: *.example.com. De esta manera, indicamos al navegador que este certificado es válido para cualquier subdominio de example.com. No voy a explicar como se generan los certificados SSL ya que buscando un poco por google se encuentran multitud de páginas al respecto. Si le vamos a dar un uso personal, podéis crear un self signed certificate. La única diferencia con los tutoriales que podáis encontrar es que como dominio introduciremos “*.<dominio>” (Por ejemplo: *.example.com).

Configuración del servidor web de Apache

Voy a suponer que en nuestro servidor tenemos configurado un servidor web Apache2 con varios host virtuales (www.example.com, mail.example.com y un servidor WebDAV para el Subversion en svn.example.com), y que el servidor sólo dispone de una dirección IP.

Lo primero que hay que hacer es poner el servidor web a escuchar en el puerto 443 (puerto estándar de HTTPS) y configurar un host virtual sobre ese puerto:

Listen 443
<VirtualHost *:443>
  ServerName *.example.com
  ErrorLog /var/log/apache2/https-error.log
 
  # Possible values include: debug, info, notice, warn, error, crit,
  # alert, emerg.
  LogLevel warn
 
  CustomLog /var/log/apache2/https-access.log combined
  ServerSignature Off
 
  SSLEngine On
  SSLCertificateFile /path/to/certs/example.com.pem
  SSLCertificateKeyFile /path/to/private-keys/example.com.key
</VirtualHost>

Con esto ya tenemos la capa SSL configurada. El certificado indicado en el parámetro SSLCertificateFile es el Widlcard SSL Certificate que hemos creado anteriormente. A partir de aquí, el “truco” está en el uso creativo del mod_proxy, que conseguiremos añadiendo la siguiente configuración dentro del hosts virtual que acabamos de crear:

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>
 
  # Proxy requests to ourselves preserving the Host header
  ProxyPass / http://localhost/
  ProxyPassReverse / http://localhost/
  ProxyPreserveHost on

Con esta configuración estamos reenviando todas las peticiones que nos lleguen a este host virtual por HTTPS hacia el propio servidor, pero cambiando el protocolo de HTTPS a HTTP. Es importante destacar la última línea, que le indica al servidor web que debe mantener la cabecera Host al hacerse la petición a sí mismo, gracias a la cual no tendrá ningún problema a la hora de determinar que página quiere ver el usuario.

Para que las aplicaciones web puedan distinguir si la petición que les llega a entrado por HTTP o HTTPS, configuraremos el host virtual para que añada la cabecera X_FORWARDED_PROTO a las peticiones que se hace a sí mismo:

  # Add the X_FORWARDED_PROTO=https to allow applications to identify
  # proxyed https connections
  RequestHeader set X_FORWARDED_PROTO https

Ya sólo queda un detalle, necesario únicamente si vamos a usar esta configuración para proteger un WebDAV. El problema de esta configuración con WebDAV viene a la hora de intentar hacer un ‘svn mv‘, por ejemplo. Este comando indica el destino en la cabecera HTTP Destination. Como el cliente se esta conectando a https://svn.example.com/repo/etc, la cabecera tendrá ese valor. Pero el host virtual que tiene la configuración de WebDAV sólo está configurado para HTTP por lo que espera que la cabecera Destination empiece por http://svn… Para solucionar la inconsistencia entre la cabecera esperada y la recibida echaremos mano del mod_rewrite:

  # Workarrounf for WebDAV Destination header
  RewriteEngine on
  RewriteCond %{HTTP:Destination} ^https://(.*)$
  RewriteRule . - [env=DESTINATION:http://%1,PT]
  RequestHeader set Destination %{DESTINATION}e env=DESTINATION

Resumen de la configuración

Una vez explicadas las diferentes partes de la configuración, os pongo toda la configuración tal cual se debe escribir en los ficheros de configuración del servidor web para que no haya problemas de “¿y esto donde va?, ¿dentro o fuera del virtualhost?” :

Listen 443
<VirtualHost *:443>
  ServerName *.example.com
  ErrorLog /var/log/apache2/https-error.log
 
  # Possible values include: debug, info, notice, warn, error, crit,
  # alert, emerg.
  LogLevel warn
 
  CustomLog /var/log/apache2/https-access.log combined
  ServerSignature Off
 
  SSLEngine On
  SSLCertificateFile /path/to/certs/example.com.pem
  SSLCertificateKeyFile /path/to/private-keys/example.com.key
 
  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>
 
  # Workarrounf for WebDAV Destination header
  RewriteEngine on
  RewriteCond %{HTTP:Destination} ^https://(.*)$
  RewriteRule . - [env=DESTINATION:http://%1,PT]
  RequestHeader set Destination %{DESTINATION}e env=DESTINATION
 
  # Add the X_FORWARDED_PROTO=https to allow applications to identify
  # proxyed https connections
  RequestHeader set X_FORWARDED_PROTO https
 
  # Proxy requests to ourselves preserving the Host header
  ProxyPass / http://localhost/
  ProxyPassReverse / http://localhost/
  ProxyPreserveHost on
</VirtualHost>

Conclusiones

Personalmente veo está configuración como una solución válida para servidores personales en los que se suelen usar self signed certificates o de CAcert. Para pequeñas empresas (con unos pocos dominios) puede ser una solución, pero los Widlcard SSL Certificates de autoridades certificadoras comerciales (cuyos certificados raíz vienen en los navegadores) no son baratos. Dependiendo del hosting creo que saldría más barato contratar IPs adicionales para el servidor y certificados individuales que no usar el Widlcard SSL Certificate en un servidor con una sóla IP.

En empresas medianas o grandes, puede justificarse el uso de Widlcard SSL Certificates si tienen un gran número de subdominios que quieren asegurar ya que puede suponer un ahorro, pero no veo el motivo de tenerlo todo sobre una sóla dirección IP. Por tanto, no veo que la configuración aquí explicada sea aplicable en este tipo de empresas.

A mi, esta solución me está funcionando muy bien y de momento no he encontrado ningún problema.

Notas adicionales

[1] Para los nostálgicos, ¿os acordáis de la guerra de navegadores?