![[Important]](/media/com_docimport/admonition/important.png) | Important |
|---|---|
|
This feature uses .htaccess files which are only compatible with Apache, Litespeed and a very few other web servers. Some servers (such as NginX and IIS) are incompatible with .htaccess files. If we detect a known to be incompatible server type this feature will not be shown at all in Admin Tools' interface. It should be noted that even if you do see it in the interface it doesn't necessarily means that it will work on your server. This depends on your server's capabilities. If you are unsure or believe it doesn't work please consult your host. |
The tool
of Admin Tools is designed to add an extra level of protection to your
site's wp-admin, asking for a username and password before accessing the
login page or any other file inside the wp-admin
directory of your site. It does so by using Apache .htaccess and
.htpasswd files, so it won't work on IIS hosts.
| Important |
|---|---|
|
Some prepackaged server bundles, such as Zend Server, and some
live hosts do not allow using .htaccess files to password-protect a
directory. If it is a local server, edit your
If you are on a live host, please consult your host about the possibility of them allowing you to use this feature on your site. |
Password-protect Administrator
If you are on a server running on Windows™, you are receiving a warning at the top of the page stating that the password will be stored to disk unencrypted. This is done due to the lack of the system-wide crypt function on the Windows platform, which causes Apache to understand password only if they are unencrypted or encrypted with a non-standard encryption scheme which does not exist in PHP.
![[Warning]](/media/com_docimport/admonition/warning.png) | Warning |
|---|---|
|
If you password your administrator directory on a Linux system
and then restore your site on a Windows server (typical live to local
site restoration) you will be receiving a blank page or an Internal
Server 500 when accessing the site. This is normal and expected. All
you have to do is to remove the |
In order to apply the password protection, simply enter a desired username and password and click on the button. After a few seconds your browser will ask you to supply the username and password you just specified. This will also happen each and every time anybody tries to access the administrator back-end of your site. In other words, you have to share the username and password with all back-end users of your site.
If you wish to remove the password protection you can either
remove both the .htaccess and
.htpasswd files from your wp-admin directory, or
click on the
button.
500 Internal Server Error when enabling this feature
If after applying the password protection you immediately receive a blank page or an Internal Server Error 500 instead of a password prompt, your server is not compatible with the password protection scheme.
In this case, the only way to gain access to your site's
administrator back-end is to remove the .htaccess
and .htpasswd files from your wp-admin directory
using an FTP application or the File Manager in your site's hosting
control panel. If in doubt, consult your host about how you can do that
before trying to apply the password protection.
If those files do not show up in your FTP client, please create two blank files with those names and upload them to your site, overwriting the existing (but invisible) ones. This will remove the password protection so that you can regain entrance to your administrator back-end.
404 Not Found error page or WordPress error page when enabling this feature
Long story cut short: ask your host to disable Apache custom error pages for HTTP status codes 401 and 403.
But why does this happen? (Optional, detailed information; you don't have to read the next paragraphs).
When you enable password protection all you're doing is create a .htaccess file. This tells Apache, your web server, that the wp-admin directory is password protected. The next time your browser tries to access anything in that directory it has to send an HTTP Basic Authentication header that contains your username and password. If it doesn't, Apache returns an HTTP 401 status which, in turn, instructs the browser to ask you for the username and password (and then store it in its authentication cache for the browsing session). This is how your browser knows it needs to ask you for a username and password.
However, HTTP 401 is technically an HTTP error status. Apache has a feature called custom error pages. Depending on the HTTP error status returned (all 4xx and 5xx codes) you can configure Apache to return a static HTML page with custom content to the browser when it sends the error code. This holds true even for the 401 status described above. The real cause of the problem you are facing is that the configured custom error page does not exist. This causes Apache to internally report the file as missing. This breaks the authentication flow and would normally trigger a 404 Not Found error page.
WordPress' .htaccess file always asks Apache to redirect missing files to its index.php file. That's how permalinks work: the URL is not a real file, Apache hands it over to WordPress and WordPress figures out which post or page to display. If it doesn't know what to do with the URL, like in this unfortunate case, WordPress displays its 404 error page.
When you disable custom error pages for the 401 error code you let Apache communicate that status directly to the browser without WordPress interfering. This lets the password protection work properly. FYI, the aforementioned error will also take place if you use your hosting control panel's directory password protection feature. It is not caused by Admin Tools. It is caused entirely by your server's configuration. Also note that most hosts do let you define and reset custom error pages through the hosting control panel.
I used that and my public site is now asking for a username and password
You have a plugin which has placed its files inside the wp-admin folder of your site. This is against WordPress best practices. Check your browser's console to find the offending plugin and report it to the WordPress Plugin Directory.