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.
administrator directory of your site. It does so by
using Apache .htaccess and .htpasswd files, so it won't work on IIS
Some prepackaged server bundles, such as Zend Server CE, 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.
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.
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 thebutton. 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
.htpasswd files from your administrator directory,
or click on the
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
.htpasswd files from your administrator
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.
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 administrator 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.
If that wasn't bad enough, Joomla is always configured to catch all missing files and try to figure out if it should try and serve a Joomla page instead. This is required for the correct operation of search engine friendly URLs. So, Joomla sees the missing file error. Not knowing what to do with it, it tries to route it through com_content (the built-in Articles component). Hard as it may try, it can't find an article category which matches the URL. This causes Joomla to throw an error. This is what ends up being displayed as the 404 or Joomla error page you are receiving.
When you disable custom error pages for the 401 error code you let Apache communicate that status directly to the browser without Joomla 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.