Configurando mod_proxy para evitar CORS (por Same Origin Policy)

Otra solución que conseguimos para evitar CORS (por Same Origin Policy) fue instalar/configurar mod_proxy como "proxy en reverso" en nuestro Apache HTTP Server. Sugiero leer este artículo también: CORS, XDM, Same Origin Policy, Prototype y JQuery.

Les dejo el pequeño HOWTO que hice:

0.- Configuración del sistema

$ cat /etc/issue
Ubuntu 10.10 \n \l

$ dpkg -l \*apache\* | grep ^i
ii  apache2-mpm-prefork                  2.2.16-1ubuntu3.1                                 Apache HTTP Server - traditional non-threaded model
ii  apache2-utils                        2.2.16-1ubuntu3.1                                 utility programs for webservers
ii  apache2.2-bin                        2.2.16-1ubuntu3.1                                 Apache HTTP Server common binary files
ii  apache2.2-common                     2.2.16-1ubuntu3.1                                 Apache HTTP Server common files
ii  libapache2-mod-php5                  5.3.3-1ubuntu9.5                                  server-side, HTML-embedded scripting language (Apache 2 module)
ii  libapache2-mod-proxy-html            3.0.1-1                                           Apache2 filter module for HTML links rewriting

1.- Pasos para la instalación del mod_proxy

1.1.- Instalación de paquetes

$ sudo aptitude install libapache2-mod-proxy-html
$ sudo a2enmod proxy
$ sudo a2enmod proxy_http

1.2.- Configuración del VirtualHost

Agregar al virtual host (Ej. /etc/apache2/sites-available/default) correspondiente lo siguiente:

ProxyRequests Off


Order deny,allow
Allow from all


ProxyPass /mio http://mio.com
ProxyPassReverse /mio http://mio.com

2.- Pruebas

Simplemente bastaría con hacer una petición a: http://localhost/mio/recurso

CORS, XDM, Same Origin Policy, Prototype y JQuery

Tiempo sin escribir nada por estos lados...

Me trae de vuelta un problema que me quitó mucho tiempo y me tuvo varias horas atascado, y como este blog va de compartir problemas y soluciones en la red, pues ahí lo dejo...

Los navegadores suelen seguir una política/restricción de seguridad conocida, llamada Same Origin Policy, que restringe la modificación de páginas/recursos -generalmente con Javascript- con contenidos obtenidos de otro lugar diferente al "origen". Esta tabla me parece perfecta para explicar qué se considera diferente del "origen".

Bueno, pues resulta que esta política se puede saltar valiéndose del concepto de CORS (Cross Origin Resource Sharing) o directamente utilizando una librería de XDM (Cross Direct Messaging), como: easyXDM.

Resulta que XDM nos parecía un hack y no queríamos valernos de este tipo de librerías; mucho más frecuentes en sitemashups. Entonces la solución era CORS. Cumplíamos con todos los parámetros, simplemente "creíamos" enviar los parámetros básicos en nuestras peticiones HTTP, a saber: Accept, Accept-Language, Content-Language, Content-Type o Media-Type (sólo dentro del rango: application/x-www-form-urlencoded, multipart/form-data y text/plain).

Y pasó lo que tenía que pasar, no funcionaba!! Estábamos utilizando Prototype porque JQuery no nos funcionaba en el navegador. Resulta que nuestro código si funcionaba en local, utilizando Firefox, con JQuery y seguía sin funcionar con Prototype.

Estuve al menos 1 hora depurando/debuggeando con Firebug y la paranoia y desesperación me llevaron hasta a probar con Wireshark. Fue cuando nos dimos cuenta de que Prototype estaba incluyendo algunos parámetros adicionales en la petición y JQuery no.

Ya estábamos más cerca de solucionar el problema. Este artículo abrió nuestros ojos defintivamente y agradezco de nuevo a su autor. Incluimos el código comentado allí y resolvimos el problema. Simplemente borra las cabeceras cuando detecta peticiones a recursos diferentes del origen. ¿Por qué JQuery si funcionaba? Porque cuando detecta peticiones a otro origen remueve los parámetros.