Support » Fixing WordPress » Authorization header missing error

  • Ate Up With Motor

    (@ate-up-with-motor)


    Two weeks ago, the Site Health Status component on one of my websites began warning “The Authorization header comes from the third-party applications you approve. Without it, those apps cannot connect to your site.”

    It suggested flushing and resetting permalinks to fix this error. I did so, which removed the error — but only for a little while. Less than 24 hours later, the error recurred. Repeating the permalink flush/reset no longer has any effect whatever on the error, even temporarily.

    I don’t use application passwords for any third-party applications, so I’m not sure why I’m getting this error.

    I tried disabling all plugins and switching to the default theme. This had no effect on the error; it persists with no active plugins and the default theme.

    My web host has been completely unhelpful. Does anyone have any suggestions of what’s causing this error and how I can fix it?

    (Curiously, my other sites, which use substantially the same list of plugins, do NOT have this error.)

Viewing 8 replies - 1 through 8 (of 8 total)
  • If you disabled all plugins and switched to the default theme, and the problem still persists, that doesn’t leave many options.

    Let me start by saying that I would try the following on a staging version of the website. If you want to try on production, that is your choice to risk.

    Potential Solutions

    Start by checking your .htaccess file. If you see this:

    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    …that’s likely the problem. You should only see that if you are using the Application Passwords feature. If you’re 100% sure you’re not using it, try deleting that line.

    If you do see it, you may want to ask yourself how it got there if you’re certain you’ve never used the Application Passwords feature before. Does anyone else have access? Perhaps you used it in the past and have disabled it since, but .htaccess did not update accordingly. Something to think about.

    If that doesn’t apply at all, you could replace all core WordPress files as well. Give that a shot (just overwrite the root WordPress files including the wp-admin and wp-includes directories). Do not mess with your .htaccess or wp-config.php files though. I’ve done this on occasion to solve some very odd WordPress behaviour.

    Good luck.

    • This reply was modified 1 month, 1 week ago by Michael Ott.
    • This reply was modified 1 month, 1 week ago by Michael Ott.
    • This reply was modified 1 month, 1 week ago by Michael Ott.
    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    The authorization header line IS present in .htaccess, which poses an obvious question: If the header is present (and it definitely was, I just checked), why is the Site Health component warning that the header is missing?

    If the header is present (and it definitely was, I just checked), why is the Site Health component warning that the header is missing?

    Good question, unfortunately I don’t have an answer to that. Could it be as simple as that it can’t actually read .htaccess and is misreporting the warning? That’s a long shot I know, but it’d be far from the first time I’ve known WordPress to throw an incorrect warning or error that led me down a wrong diagnostic route.

    If you ever figure it out, I’d be curious to know.

    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    I just tried manually deleting the directive from .htaccess, flushing the permalinks again, and allowing WordPress to reset them (which recreated the HTTP:Authorization directive). This definitely restored the directive to .htaccess, but the warning persists.

    The persistent warning is odd behaviour, for sure.

    Perhaps something in the database related to the Password Application has a value that causes WordPress to think it’s in use, which then triggers a .htaccess check and comes back with a warning when it doesn’t find the directive. That’s highly unlikely but I can’t help grasp at straws at this point.

    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    The thing is, the directive IS there — it was placed there by WordPress core itself, and I verified that is was — so I can’t fathom why it wouldn’t find it.

    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    Following a suggestion offered by a user of the Really Simple SSL plugin, I switched the site’s PHP version from 7.4 non-FastCGI to 7.4 FastCGI. After refreshing permalinks again, the error message disappeared and Site Health now says “The Authorization header is working as expected.”

    So, as the developer suggests in the post linked above, this appears to have been a server configuration issue. I want to wait a bit to see if the issue recurs before pronouncing it fixed, but for the moment, it appears it may be.

    (Note: After changing the PHP version, it appears it’s necessary to reset the permalinks again, to make sure that WordPress registers that the Authorization directive is indeed present.)

    Excellent. Fingers crossed the solution sticks this time.

    • This reply was modified 1 month, 1 week ago by Michael Ott.
Viewing 8 replies - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.