Recentemente, axustando a configuración dun Wordpress que instalamos nos servidores dun cliente apareceunos un problema bastante singular.
Nos nosos servidores o sitio web funcionaba correctamente sobre https e aparentemente replicamos a configuración do cliente. O cliente recibe as peticións nun proxy reverse que envía ao servidor coa aplicación en http.
O problema era que no servidor do cliente non se cargaban os estilos, nin os js nin as fontes porque o navegador tentaba cargalos por http en lugar de https, considerábaos inseguros e polo tanto bloqueábaos. Ademais, tampouco podiamos acceder á zona de administración de Wordpress porque o navegador mostraba o seguinte erro (ERR_TOO_MANY_REDIRECTS) .
A configuración no noso wp_config.php era a seguinte:
/* 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';
As últimas liñas corresponden á forma recomendada de manexar esta configuración en WP, como se pode ver aquí: https://codex.wordpress.org/Function_Reference/is_ssl .
O servidor apache, que recibía as peticións externas, estaba configurado da seguinte forma (incluímos só as instrucións relevantes) e enviábaas ao servidor no que estaba instalada a aplicación por http:
<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 pode ver, inclúese a instrución que en teoría debería enviar a indicación do https RequestHeader set X_FORWARDED_PROTO 'https'.
Tras investigar na rede (http://www.jpereira.net/gestion-documental/wordpress-mod-proxy-ssl , https://snippets.webaware.com.au/snippets/wordpress-is_ssl-doesnt-work-behind-some-loade-balancers/ ), a nosa conclusión é que nesa viaxe entre servidores pérdese a variable ou non se chega a enviar. Por este motivo, o servidor coa aplicación non pode saber que estamos sobre https. Temos que indicar que a nós non nos funcionou ningunha das solucións anteriores e tivemos que forzar directamente a variable que indica estar sobre https poñéndoa directamente no wp_config desta forma:
$_SERVER['HTTPS']='on';
A partir deste momento o sitio web funciona correctamente, poida que non sexa a solución ideal, pero despois dunha semana pelexándonos con este problema é a única que atopamos.
Agardamos que este artigo vos axude se vos encontrades co mesmo problema.
