Recientemente, ajustando la configuración de un WordPress que instalamos en los servidores de un cliente, nos encontramos con un problema bastante singular.
En nuestros servidores el sitio web funcionaba correctamente sobre https y aparentemente replicamos la configuración del cliente. El cliente recibe las peticiones en un proxy reverse que envía al servidor con la aplicación en http.
El problema era que en el servidor del cliente no se cargaban los estilos, ni los js ni las fuentes porque el navegador intentaba cargarlos por http en lugar de https, los consideraba inseguros y por tanto los bloqueaba. Además, tampoco podíamos acceder a la zona de administración de WordPress porque el navegador mostraba el siguiente error (ERR_TOO_MANY_REDIRECTS) .
La configuración en nuestro wp_config.php era la siguiente:
|
1 2 3 4 5 6 |
/* Activo acceso https */ define('FORCE_SSL_LOGIN', true); define('FORCE_SSL_ADMIN', true); define('WP_HOME','https://xxxx.imaxin.com/'); define('WP_SITEURL','https://xxxx.imaxin.com/'); if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on'; |
Las últimas líneas corresponden a la forma recomendada de manejar esta configuración en WP, como se puede ver aquí: https://codex.wordpress.org/Function_Reference/is_ssl .
El servidor apache, que recibía las peticiones externas, estaba configurado de la siguiente forma (incluimos solo las instrucciones relevantes) y las enviaba al servidor en el que estaba instalada la aplicación por http:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
<VirtualHost *:80> ServerName xxxx.imaxin.com RewriteEngine On RewriteCond %{HTTP_HOST} !=on RewriteRule ^/(.*) https://xxxx.imaxin.com/$1 [R,L] </VirtualHost> <VirtualHost *:443> ServerName xxxx.imaxin.com:443 #ServerAlias www.xxxx.imaxin.com:443 SSLCertificateFile /etc/apache2/ssl/xxxx/xxxx.crt SSLCertificateKeyFile /etc/apache2/ssl/xxxx/xxxxx.key SSLCertificateChainFile /etc/apache2/ssl/xxxx/xxxx.csr ProxyPreserveHost On RequestHeader set X_FORWARDED_PROTO 'https' <Location /> ProxyPass http://w_xxxx.imaxin.com/ ProxyPassReverse http://w_xxxx.imaxin.com/ </Location> </VirtualHost> |
Como se puede ver, se incluye la instrucción que en teoría debería enviar la indicación del https RequestHeader set X_FORWARDED_PROTO ‘https’.
Tras investigar en la red (http://www.jpereira.net/gestion-documental/wordpress-mod-proxy-ssl, https://snippets.webaware.com.au/snippets/wordpress-is_ssl-doesnt-work-behind-sume-load-balancers/), nuestra conclusión es que en ese viaje entre servidores se pierde la variable o no se llega a enviar. Por este motivo, el servidor con la aplicación no puede saber que estamos sobre https. Hemos de indicar que a nosotros no nos funcionó ninguna de las soluciones anteriores y tuvimos que forzar directamente la variable que indica estar sobre https poniéndola directamente en el wp_config de esta forma:
$_SERVER[‘HTTPS’]=’on’;
A partir de este momento el sitio web funciona correctamente, puede que no sea la mejor solución, pero después de una semana peleándonos con este problema es la única que encontramos.
Esperamos que este artículo os pueda ayudar si os encontráis con el mismo problema.