Surprising pitfalls caused by Jetpack when implementing HTTP Auth on WordPress sites
If you are working with WordPress in the field of web production, you have considered the introduction of "BASIC authentication (HTTP Auth)" at least once.
There are many reasons for this, to avoid showing the site in production to the outside world, to create a client-only verification environment.
However, I recently encountered an unexpected clash between such a convenient HTTP Auth and a popular plugin called Jetpack.
Today, I would like to share the trouble and the road to resolution.
Contents
Contents
Why HTTP Auth
?While WordPress is used all over the world, it is an easy target for attacks.
Therefore, it is very common to use BASIC authentication to avoid exposing the site or staging environment during production to the outside world.
For example, in Apache, you would write the following in .htaccess:
apache
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /path/to/.htpasswd
Require valid-user
By including this setting, you can set up a "first checkpoint" where you enter your ID and password before reaching WordPress.
It is especially effective for securing the admin screen and login page.
The trouble was caused by Jetpack
.This time, we were working on a staging environment for a corporate website.
They changed the login page to a custom URL with the SiteGuard WP Plugin and also implemented BASIC authentication to implement double defense.
However, when it started operating, this phenomenon occurred.
- Log in to WordPress with BASIC authentication The
- top page of the management screen and the list of posts can be viewed normally .
- When you open the plugin list page (/wp-admin/plugins.php), you will be asked for BASIC authentication again .
- Even if you break through authentication, you may get a "500 Internal Server Error" or "Connection reset"
At first, I thought it was a misconfiguration of .htaccess, so I reviewed the way I wrote it.
However, other dashboard pages can be displayed without any problems.
Despite this, it was very puzzling that only certain pages were authenticated again.
How Jetpack works
As weinvestigated, we found out that the cause was Jetpack.
Jetpack is very versatile, offering site statistics, image CDN, security features, and more.
But behind the scenes, it uses REST APIs and XML-RPC to communicate with WordPress.com.
This communication is blocked by the BASIC authentication wall.
When Jetpack accesses the admin screen, it taps Ajax and REST APIs to integrate WordPress.com and authentication.
If BASIC authentication is set, all API calls will bounce with 401 Unauthorized.
As a result, Jetpack causes an error in the admin and requires re-authentication during page transitions.
In fact, the plugin list page had a lot of Jetpack-related API communication, so the reauthentication loop was particularly noticeable.
final solution
The final action we took was to disable Jetpack.
Once disabled, all reauthentication issues have been stopped.
Page transitions in the admin screen have also become smoother, and HTTP Auth and WordPress have returned to a form where they coexist properly.
Be careful when using Jetpack and HTTP Auth together
.What I want to highlight here is the incompatibility between Jetpack and HTTP Auth.
All plugins that use REST APIs are blocked by BASIC authentication barriers.
In particular, since Jetpack requires external communication, there is a very high possibility that the management screen will become unstable if HTTP Auth is set.
The WordPress admin has more API communication behind the scenes than you might think.
When introducing HTTP Auth, you should be aware that using it with "plug-ins that communicate with external services" is risky.
Conclusion
If you don't need external integration in a staging or closed environment, HTTP Auth is enough.
If you need to work with production or external services, it's safer and more comfortable to use two-factor authentication and IP restrictions instead of using Jetpack.
Jetpack is useful, but the reality is that it is very incompatible with HTTP Auth.
At the production site, it was a lesson that "putting anything in just because it's convenient" can lead to big problems.
When implementing HTTP Auth, be sure to recheck your relationship with Jetpack and other external communication plugins.
I hope it will be helpful for those who are worried about the same thing!
