Quizás en alguna instalación de WordPress te haya sorprendido que la herramienta de salud del sitio te indica que tu web necesita mejoras debido a que falta la cabecera de autorización o a que la cabecera de autorización no es válida.
¿A qué es debido este aviso?¿por qué es un problema de salud del sitio? ¿es un problema de seguridad? ¿tiene solución?
Índice de contenidos
¿Qué es la cabecera de autorización?
Cuando accedes a la herramienta de salud del sitio de WordPress y despliegas la advertencia de mejora, verás que te indica el detalle del problema.
Por ejemplo:
Los problemas pueden ser 2:
- Falta la cabecera de autorización.
- La cabecera de autorización no es válida.
Además, en la descripción te indicará que la cabecera de autorización proviene de las aplicaciones de terceros que apruebes, y que sin ella estas aplicaciones no pueden conectar con tu sitio, sea lo que sea que signifique eso.
Y te ofrece un enlace para «purgar los enlaces permanentes» que te lleva directamente a los ajustes de enlaces permanentes de la administración de tu WordPress.
Bien, pues todo esto es debido a que WordPress ha detectado que alguna aplicación de terceros, o sea, algún plugin o tema, ha tratado de conectarse mediante la REST API y no ha podido debido a que falta o no es válida la llamada cabecera de autorización.
Esto puede pasar a partir de la versión 5.6 de WordPress, que es cuando se introdujeron las contraseñas de aplicación y, lo más habitual es que sea debido a que las reglas de enlaces permanentes de tu sitio no estén actualizadas o no estén correctas, e impidan que se realice la autorización.
¿Es un problema de seguridad?
Aunque cuando la prueba es correcta aparecer en la sección de seguridad, en realidad no, es un problema de funcionamiento, que impedirá que funcione alguna característica de alguno de tus plugins o tema.
Cómo solucionar problemas con la cabecera de autorización de WordPress
Bueno, dicho lo anterior, lo más normal es que sea debido a que, efectivamente, falta la cabecera de autorización, o que no está bien definida, así que vamos a ver las soluciones.
Actualiza temas y plugins
Hay veces en que simplemente es que algún plugin o tema no estaba realizando bien la conexión, así que una comprobación que no te costará nada, antes de meternos en añadir cabeceras que faltan o modificar cabeceras, es tener tu WordPress actualizado y al día.
Es una prueba tan sencilla como actualizar todos los plugins y temas que tengas instalados.
Una vez hecho esto pásate por la herramienta de salud del sitio para comprobar si persiste el problema con la cabecera de autorización o no.
Purga los enlaces permanentes
Pues sí, otra solución es hacer caso a la pantalla de información de la herramienta de salud del sitio y purgar los enlaces permanentes.
¿Que cómo se hace eso? Muy sencillo, simplemente guarda cambios como si hubieses modificado algo en los ajustes, pero sin modificar nada en los ajustes.
Ve a la administración de tu WordPress, en concreto a Ajustes → Enlaces permanentes, y dale clic al botón de «Guardar ajustes»
A continuación pásate, lógicamente, por la salud del sitio y revisa a ver si se solucionó la advertencia.
Modifica manualmente las reglas de enlaces permanentes
Si lo prefieres, puedes actualizar manualmente el archivo .htaccess que, históricamente, solía ser algo así:
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPressY digo «históricamente» porque desde WordPress 5.6 ya no es así, y deberías cambiarlo.
Puedes hacer una de estas 2 cosas:
- Añadir manualmente esta línea antes de la primera
RewriteRule:RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] - Sustituir las reglas existentes al completo por estas (nuevas):
# BEGIN WordPress # Las directivas (líneas) entre «BEGIN WordPress» y «END WordPress» son # generadas dinámicamente y solo deberían ser modificadas mediante filtros de WordPress. # Cualquier cambio en las directivas que hay entre esos marcadores serán sobrescritas. RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPress
Verás que el resultado es el mismo, simplemente añades la regla de rewrite de la cabecera de autorización, justo de lo que nos estaba avisando la herramienta de salud del sitio con su advertencia de que faltaba o no era válida.
Esta nueva línea del archivo .htaccess se añadió a partir de WordPress 5.6, precisamente por lo que te comenté al principio.
Esta línea ayuda a gestionar la cabecera de autorización para las solicitudes HTTP procedentes de cualquier aplicación de terceros aprobada. Sin una gestión adecuada de la cabecera de autorización las aplicaciones no podrán conectarse a tu sitio.
Así que, los sitios que utilizan reglas de enlaces permanentes obsoletas, no tendrán la nueva línea en el archivo .htaccess. Esto provoca errores cuando WordPress intenta procesar las peticiones.
El error de salud del sitio ocurre porque WordPress espera ciertas cabeceras de autorización que no están incluidas en la solicitud.
Activa manualmente la cabecera de autorización
Un método para solucionar el aviso de la cabecera de autorización, alternativo a los anteriores, que solo debes probar si no te funcionan los que ya hemos visto anteriormente, es activar manualmente la cabecera de autorización.
En un servidor Apache tendrías que añadir lo siguiente al archivo .htaccess:
<IfModule mod_setenvif> SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 </IfModule>
En un servidor Nginx deberías añadir esto a la configuración de FastCGI:
fastcgi_pass_header Authorization;
¿Funciona?
Pues claro, salvo que me digas lo contrario en los comentarios, normalmente con la solución sencilla, la de purgar los enlaces permanentes, se arregla el problema, porque WordPress sustituye las reglas anticuadas del archivo .htaccess por las nuevas, añadiendo ya la cabecera de autorización correcta.
O si, por algún motivo, prefieres hacerlo manualmente, también funcionan los otros métodos. Lo he probado en decenas de instalaciones con este aviso de la cabecera de autorización que da la herramienta de salud del sitio.
Comprobarlo es sencillo, solo tienes que ir de nuevo a la herramienta de salud del sitio y habrá desaparecido la advertencia, pasando ahora a ser una más de las pruebas completadas.
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
Hola Fernando,
Tu artículo está muy claro pero no me ha funcionado ninguna de las soluciones que propones.
Como último recurso he optado por incluir este código al final de mi archivo htaccess pero sin ningún resultado.
Estoy convencido de que mi servidor es Apache pero ¿cómo puedo estar seguro del todo?
Muchas gracias por tu ayuda.
También puede ser un plugin de seguridad que esté bloqueando la conexión, pero antes probaría con el .htaccess pero poniendo completo el código, con la comprobación de setenvif, como en mi ejemplo.
Si te funcionan otras reglas de .htaccess tu servidor es Apache
Muchísimas gracias por tu rapidísima respuesta, Fernando, eres muy amable.
Me temo que, salvo que no te haya comprendido, mi htaccess ya cuenta con el código completo. Ya estaba ahí, (no lo he puesto yo):
# BEGIN WordPress # Las directivas (líneas) entre «BEGIN WordPress» y «END WordPress» son # generadas dinámicamente y solo deberían ser modificadas mediante filtros de WordPress. # Cualquier cambio en las directivas que hay entre esos marcadores serán sobrescritas. RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPressPor lo que dices del plugin de seguridad, el único que utilizo es el Really Simple SSL.
A parte de ese, los mayores plugins que utilizo son
Elementor
Elementor Pro
WP Rocket
Yoast Premium
Ultimate Member
El tema es OceanWP, incluídas las extensiones de pago.
Todo está a la última, con todas las actualizaciones cargadas.
Además de todo esto la web está vigilada por SiteLock.
¿Se te ocurre que pueda ser alguno de esos el culpable?
Si finalmente no puedo econtrar la solución, ¿es un problema grave?
De nuevo, muchísimas gracias por tu gran ayuda.
ionos bloquea por defecto las peticiones es imposible que se puedan hacer estas llamadas si no te dan un servidor dedicado
Pues cambia de hosting ya
Hola Fernando, tengo una woocommerce en funcionamiento desde hace 8 meses aproximadamete, y como todo va genial, aparecemos en google y todo funciona correcto. Perooooooo, los enlaces permanentes no los tengo bien. No los personalice, y mis entradas son tal que https://mitienda.com/?product=mi-producto-puesto-a-vender
Me gustaria saber el camino a seguir para personalizar mis enlaces, para no romperlos en google y en general donde los clientes entrar a nuestros productos.
Que camino paso a paso hacer para realizar el cambio correctamente sin dañar nada.
Gracias de antemano