WordPress: Prevent access to wp-login.php when the wp-admin directory has already been protected

The problem: You’ve used .htaccess / .htpasswd to restrict access to the wp-admin directory of your WordPress installation. However, when someone accesses wp-login.php, they can simply click “cancel” or press the escape key in the authentication dialog to reach the WordPress login page:

Click on “Cancel” here…
…and you still reach the WordPress login page (doesn’t look great, but works).

The solution

You also have to explicitly protect the wp-login.php file. Open the .htaccess file in the root directory (not in the wp-admin directory) and add something like this1:

AuthType Basic
AuthUserFile "path/to/.htpasswd"
require valid-user

You’ll have to replace path/to/.htpasswd with the path to your .htpasswd file (which should exist if you’ve already restricted access to your wp-admin directory).

Now, if someone cancels the authentication dialog, they’ll be directed to the default “Error 401” page:

Detailed information on authentication on Apache servers can be found in the official documentation. While there are lots of terrible articles out there which only regurgitate incomplete information for SEO purposes, I did find a comprehensive tutorial on how to protect wp-login.php and the wp-admin directory here.

Note: You may still want to install a WordPress security plugin like Cerber. This is how I discovered that I had forgotten to protect wp-login.php on one of my websites.


1 Wondering why I didn’t include the AuthName directive? The text is not shown in Chromium-based browsers.

WordPress sharing button opens new window with same post

The problem:

Clicking on the JetPack sharing buttons in WordPress opens a new window with the parameter ?share=... added to the URL. However, instead of being redirected to twitter or Facebook or wherever you wanted to go, you’re redirected to the post itself again.

The solution:

In my case, this was caused by the “Redirect ugly URL’s” setting in the popular Yoast WordPress SEO plugin (marked as “not recommended”, obviously for good reasons):
Clean permalinks - not recommended

After unchecking this option, sharing worked as expected.

If you don’t want to disable this feature, adding “share” to the list of variables not to clean should also fix the issue:
Variables not to clean

Unencrypted content: a threat to Google’s business model

Google’s recent announcement to give a (currently still small) ranking boost to websites using HTTPS is undoubtedly going to make the web safer for everyone.

Missing from the discussion is the fact that unencrypted content and unscrupulous ISPs present a small, but growing threat to Google’s business model. Google depends on ad revenue, and insecure connections allow third parties to tamper with data while in transit. ISPs can use this to their advantage by injecting their own ads. This is already happening: see here or here and this topic on reddit. It was also briefly mentioned in one of the comments under the original “ranking boost” announcement:

HTTPS ads comment google

HTTPS ensures data integrity and would make ad injection not only technically far more difficult, but also most certainly illegal. This also explains why Google says that even simple “content sites” should use HTTPS: they might not collect any user data, but they can still serve ads.

Being a good citizen of the web” and making the web safer for everyone sounds nice and is certainly something many people working at Google have in mind. However, it would be naive to assume that Google isn’t also looking out for it’s own commercial interests.