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:
|
1 2 3 4 5 6 7 |
/* 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:
|
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 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.
