Detección y redirección de móviles con Apache mod_rewrite.

Cuando se desarrollan aplicaciones web o versiones móviles de sitios una aspecto fundamental es la detección del móvil y sus capacidades existen 2 opciones para realizar esta tarea ambas utilizan base de datos formatos XML con las características de los móviles una es opensource WURFL y la otra es Device Atlas la cual funciona en base a licencias, gratuita para evaluación con la data de ambas es posible implementar la detección del móvil y sus capacidades.

Ahora bien como dice el titulo de este articulo detección y redirección con Apache mod_rewrite , si no se requiere una solucion compleja lo mas sencillo y rápido si se esta trabajando con Apache es usar su modulo de re-escritura de url ( mod-rewrite ) y eso es mediante unas cuantas reglas en un archivo .htaccess en el directorio como estas:

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} ^(Android|BlackBerry) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(Motorolla|Nokia|Samsung|SonyEricsson) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} iP(hone|od) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} .*Mobile.*Safari

RewriteRule ^$ http://movil.midominio.com  [R=301,L]

La deteccion es proporcionada por las expresiones regulares evaluadas de la variable “HTTP_USER_AGENT” y la redireccion por la expresion “RewriteRule ^$ http://movil.midominio.com [R=301,L]” en este caso por ejemplo tenemos un sitio en “midominio.com” y una version movil en “movil.midominio.com” el htaccess redireccionara cada peticion que sea movil al subdominio automaticamente.

Configurando Mercurial hgwebdir + Apache + pygments

Para los ultimos proyectos que he trabajado he venido usando Mercurial para el control de version (SCM) es muy versatil, ha sido portado a diferentes plataformas se ejecuta en Linux/Windows/FreeBSD/Solaris, esta hecho en python y es similar a Git ademas de ser utilizado por diferentes proyectos grandes como Netbeans y otros.

Este mini-howto esta basado en la documentacion encontrada en la wiki de Mercurial con algunas modificaciones para adaptarlo a la distro que uso(Fedora 10) y agregando el uso de pygments para el color de la sintaxis.

lo necesario para iniciar:

  • Apache web server
  • Mercurial 1.1
  • Pygments
  • Python 2.5

la version de mercurial que viene con Fedora 10 al momento de escribir esto era 1.0.2 por lo que tuve que descargar la nueva version e instalarla, si la nueva version ya se encuentra en los repositorio solo habra que instalar normalmente con yum.

wget http://www.selenic.com/mercurial/release/mercurial-1.1.1.tar.gz
tar xzvf mercurial-1.1.1.tar.gz
cd mercurial-1.1.1
# Editamos el archivo Makefile
# cambiamos PREFIX=/usr/local a  PREFIX=/usr
# si python esta bien instalado y sus dependencias ejecutamos

make all;  make install;  hg version
# se mostrara algo similar a esto "Mercurial Distributed SCM (version 1.1+20081203)"

# loggeado como usuario root
yum install -y python-pygments httpd

Ahora que ya tenemos todo lo necesario configuraremos el cgi de Mercurial y los repositorios.

# siempre como root creamos los siguiente directorios
mkdir -p /var/www/hg/repos

Creamos el archivo de configuracion “hgweb.config” en /var/www/hg/

[collections]
repos/ = repos/
[web]
style = gitweb

copiamos el cgi “hgwebdir.cgi” en /var/www/hg/ y le cambiamos los permisos

chmod a+x hgwebdir.cgi

ahora configuramos el cgi en Apache, creamos un archivo de configuracion “hg.conf” en /etc/httpd/conf.d

ScriptAliasMatch ^/hg(.*) /var/www/hg/hgwebdir.cgi$1
<Directory /var/www/hg>
Options ExecCGI FollowSymLinks
AllowOverride None
</Directory>

Predeterminadamente el web server Apache que viene en Fedora incluira todas los archivos de configuraciones en /etc/httpd.conf.d/ con el sufijo “.conf”

comprobamos la configuracion con

# esto debera retornar un mensaje de 'Sintaxis is OK'
/usr/sbin/httpd -t

Ahora queda configurar los repositorios, creamos un proyecto llamado “zf-test”

mkdir zf-test
hg init
hg add
hg ci -m "repositorio inicializado"
cd ..
mv -r zf-test /var/www/hg/repos/

Una vez inicializado el repositorio y agregado los archivo lo movemos a al directorio de los repositorios y configuramos el repositorio del proyecto dentro del directorio .hg creamos un archivo llamado “hgrc”

[web]
contact = JM
description = Aplicacion de Prueba Zend Framework.

style = gitweb
allow_push = *
allow_archive = zip gz bz2
push_ssl = false

pygments_style = autumn

[extensions]
hgext.highlight =

La configuracion indica lo siguiente style es la plantilla que usar hgwebdir para mostrar el directorio del proyecto en el browser, “allow_push = *” permite hacer cambios a cualquiera, esto esta asi porque esta pensado para funcionar en una intranet o red privada, si se hiciera publico se podria implementar las extensiones de mercurial para ACL y autenticacion via http con apache ademas de usar SSL para las conexiones y restringir los usuario que pueden hacer “push” o escribir en el repositorio.

La opcion allow_archive permite bajar el repositorio del proyecto completo en un archivo comprimido en formato zip, bz2 o gzip, la opcion hgext.highlight activa el coloreado de sintaxis para los archivos y el diff  utilizando pygments.

La libreria pygments cuenta con varios esquemas el usado aqui es “autumn” el usado por default por mercurial es “colorful”

El cgi hgwebdir puede usar otras plantillas que vienen con mercurial que son: gitweb, coal, monoblue, spartan y paper.

el paso mas importante para finalizar, para permitir la escritura y ejecucion del cgi el propietario de los repos y el cgi debe ser el usuario del web server Apache, en este caso es “apache”

cd /var/www
chown apache:apache -R hg

He aqui algunos screenshots del hgwebdir usando la extension pygments corriendo en Apache.

mercurial-repositories-index
mercurial-repositories-index
Sumario del repositorio del proyecto
Sumario del repositorio del proyecto
Vista de archivos en el repositorio
Vista de archivos en el repositorio
Pygments en accion
Pygments en accion
pygments diff
pygments diff
Mercurial Visual Graph extension
Mercurial Visual Graph extension

Referencia:

Mercurial

PHP, tokens y Forms

Por lo general es una buena practica garantizar la integridad de los datos que se envia desde un formulario a un script en la web, para ello se pueden utilizar varias tecnicas como: solo buscar por datos esperados en los campos del formulario, usar un codigo captcha y en mi opinion una de las mejores tecnicas utilizar un token para validar la integridad de los datos.

para demostracion un pequeño codigo de ejemplo:

<?php
// codigo en el encabezado del form
$randomkey = "suP3rR4nDKeY";
$fixedkey = "123lsdlas345"
$salt = time(); // correspondera a un id que se enviara en un campo oculto
// token debera ir en un campo oculto del formulario.
$token = sha1($randomkey . $fixedkey . $salt);
?>
<input id="id" name="id" type="hidden" value="<?php echo $salt; ?>" />
<input id="token" name="token" type="hidden" value="<?php echo $token; ?>" />

Una vez generado el token este sera validado por el script que recibira la informacion del formulario verificado el token garantizara que los datos son validos y han sido enviados desde nuestro formulario.

Una vez validadas las entradas y teniendo los datos del id y el token se regenera el token para comprobarlo usando las 2 key que se usaron el formulario

// $id_form es el id obtenido del formulario
// $form_token es el token del formulario
$randomkey = "suP3rR4nDKeY";
$fixedkey = "123lsdlas345"
$check_token = sha1($randomkey . $fixedkey . $id_form);
if ($form_token == $check_token ) {
print "form data esta OK";
} else {
die("Token invalido");
}

asi con el uso del token se garantiza la integridad de los datos y su procedencia, si alguien quisiera atacar el form tendria que conocer las llaves y el timestamp que se genera al cargar el form, adicionalmente siempre es recomendable realizar una doble validacion una utilizando javascript y en caso de ser deshabilitado, contar con una validacion php o en el lenguaje que se utilice para procesar el formulario.