Freeola Internet Get Dotted Domains Blog Guides Chat

Viewing Thread:
'Password protecting your web site'

Sun 25/02/07 at 23:46:
"It goes so quickly"
Posts: 4,104
Password protect a web page, web pages, or a whole directory

By default, once you’ve uploaded your web pages, they will be accessible by anybody with an Internet connection, who either know your web address, or find your site via Google. However, there may be parts of your web site (or the whole site) that you’d rather keep restricted, for one reason or another.

Most modern web browsers include built-in support for what is known as “basic authentication”, which allows a web page, a series of web pages, a directory, or a whole site to be accessed only by users who have authorisation by the site owner (this being you), in the form of a username and a password.

When the user comes across a restricted web page, the web browser will see it requires a username and password, and so asks the user for these via a log-in box. The log-in box will appear differently depending on which web browser the user is using, but the concept is the same – the user is asked for a username and password. Here are a couple of example log-in boxes from Internet Explorer (1, 2), Opera (3, 4), and Mozilla (5, 6).

When the user enters their username and password, the web browser will send it to the Freeola web servers, which will then check their authenticity. If they are valid, the web page is shown, if not, the user is greeted with an error message.

To achieve this, we’re going to make use of a programming module known as mod_auth, which is available free from Freeola. You (and your visitors) won’t need to install any new software on your machine, or ask Freeola to enable anything, as it’s all ready and waiting for you. All you need to do is create two (maybe three) new files to store the authentication details in, create your desired usernames and passwords, and decide which files and / or directories you want to protect.

It should be noted that this is “basic authentication”, and is in no way a replacement for a high-grade secure service with an SSL connection. You shouldn’t use this type of log-in for any type of important and private data from anybody (such as names, addresses, phone numbers, etc). For example, this would not be suitable for Freeola’s customer control panel, because the password encoding used is minuscule. It does carry the advantage of being quick and easy to implement though, so if all you want to do is hide some web pages behind a password, this will satisfy.

A new type of file!

To make use of “basic authentication” requires creating a file with no standard name, but with a longer file extension. While you’re probably used to files appearing as filename.ext (filename DOT extension), the files that you’ll uploaded to your web space will be in the form of .ext (DOT extension) only. This may cause problems for you in the beginning, as Windows generally likes to add a file extension to any saved file.

You can create the required files in Notepad, but when saving the file, you may need to add quotation marks around the name you’re using, to ensure Windows doesn’t add a .txt to it. You may also see your Windows directory listings looking a little different, because these new files don’t have filenames that appear underneath the icon.

The two files you’re going to need should be saved as .htaccess and .htpasswd. You will also need a file named as .htgroup if you want to make use of the group option. These files will need to be uploaded to your root directory, but not within your htdocs folder.

It should also be noted that these types of files can have some funny results when improperly coded, and so it isn’t recommended that you play about with them on an important web site, as incorrectly written files like this will cause an internal web server error. If this is the case for you, Freeola allow you to create multiple web spaces, so you can create a temporary web space to test out your files before putting them on a live site.

You may also find that your FTP software will not see these files once you’ve uploaded them (Windows Internet Explorer 7’s FTP mode appears to do this), meaning it’s difficult (or impossible) to delete them. If this is the case for you, you can overwrite the existing file with a blank one if you have problems (or you just want to remove it), and it should get your site working again, while you get in touch with Freeola to remove the file completely.

If this is cause for concern when uploading your completed files, be sure to do it during Freeola office hours, so you can get in touch quickly if a problem arises.

For those who haven’t been scared away, lets get started.

Creating your passwords file!

The password file is where your username and password combinations will be stored, and once uploaded, will be the file that the Freeola web servers reference each time somebody tries to log in to a protected web page. Each username and password combination needs to appear on a separate line, and is formatted as the “username” (un-encoded), followed by a “colon”, followed by the “password” (encoded), without any spaces between the three.

Because your password has to be encoded within the .htpasswd file, you’ll need to create it in it’s encoded form first, rather than just typing it in as plain text to the file. To do this, you can use this online encoding tool, which will ask you for the desired username and password combination. The resulting text will need to be copy-and-pasted in to your .htpasswd file, with one line per username / password combination.

As an example, below are five username and password combinations that we want to make use of on our web site:

Username: chris
Password: test

Username: bob
Password: pass25

Username: ted
Password: word85

Username: Bill
Password: 7tQH7

Username: zoe
Password: MyPass

… which we are now going to run through the online encoding tool, and copy-and-paste the results in to our .htpasswd file.

The username isn’t encoded in any form, neither is the colon (:), and is included in the utility linked above for pure convenience. The password is encoded, so that if anyone were to access the .htpasswd file, it would not be immediately obvious as to what the passwords were.

If we run each username and password combination through the utility linked above, the resulting code would look like this:


… which would need to be copy-and-pasted in to the .htpasswd file, one line per combination.

Naturally, you’ll need to create your own username and password combinations to suite your sites needs. You should also be a little more original with your password choices than this article.

Make sure you take note of the case you use for your usernames and passwords, as capital letters are looked on as being difference from small letters. For example, Bill and bill are not considered the same thing.

Creating your groups file!

If you want to set up groups of users, then you’ll need to create a .htgroup file. Creating a group allows you to define a series of usernames that can be referenced to later on, and restricts users based on their group type.

For example, you may want to restrict access to one file to only a few people, while wanting another file to be reserved for another set of people.

Within the .htgroup file, you can create a new group on each line, and set out which usernames (separated by a space) are to be associated with that group. Our example below creates two groups, one called “oldpeople”, one called “newpeople”. The “oldpeople” group contains bob and ted, whereas the “newpeople” group consists of Bill and zoe.

oldpeople: bob ted
newpeople: Bill zoe

The above would need to be copy-and-pasted in to the .htgroup file, but is optional. If you don’t feel the need to define any groups, you do not need a .htgroup file. When adding usernames, be sure to make a note of the case that each one uses.

Creating your main management file!

The file that’ll manage all your protection code is the .htaccess file. This will need to go within your htdocs folder.

The three lines of code you’ll need include the location of your password file (AuthUserFile), the type of authentication (AuthType) and the text that appears on the log-in box (AuthName). If you are creating a group file (.htgroup), you’ll also need to include its location (AuthGroupFile).

You can copy and paste the code below in to you .htaccess file, and change the directory value(s) and AuthName value as required (the code below assumes a web space ID of sr0123456):

AuthUserFile /freeola/users/6/5/sr0123456/.htpasswd
AuthGroupFile /freeola/users/6/5/sr0123456/.htgroup
AuthName "My Web site (Protected)"
AuthType Basic

If you’re not going to include a group file, remove the line AuthGroupFile /freeola/users/6/5/sr0123456/.htgroup from the above. If you’re also unsure as to what your Freeola directory address is, you can find out using the online encoding tool mentioned above. It should be noted that this is only as reliable as you typing in your web space ID correctly, and does not connect to Freeola’s system to check it is accurate.

The text My Web site (Protected) will appear within the log-in box, and can be replaced with something else if you’d prefer.

Protecting your pages!

Also within your main .htaccess file, you’ll now need to define your protection rules, using the require keyword, which lets you set who can access a particular file / directory. This can either be anybody who has a username and password (using the value valid-user), single user (defined by a username, such as zoe) or a group (defined by the given group name, such as newpeople).

If you want to have your whole web site available to all your usernames and passwords, simply add the line:

require valid-user

… to your .htaccess file, and your whole web site will be password protected.

If you want to be a little more selective, you can use the code block to assign the require keyword to a specific file within your web site. For example, to restrict access to members.htm, you could add the following to you .htaccess file:

require valid-user

Alongside the blanket valid-user value, two other sub-keywords you may want to make use of with require is user and group, which allow you to restrict your web site to a single user, or a group of users.

If we were to create a single web page for each user, and wanted to restrict it to that user alone, we can use the following within the .htaccess file:

require user bob

require user zoe

With the above, only bob can access bob.htm, and only zoe can access zoe.htm.

To restrict a page to one of our previously designated groups (if the .htgroup file exists), we change the sub-keyword from user to group, and add the name of the group accordingly:

require group oldpeople

require group newpeople

With the above, only bob and ted can access oldusers.htm because they were added to the oldpeople group, while only Bill and zoe can access newusers.htm, because they were added to the newpeople group, as set out within the .htgroup file.

Protecting directories!

To protect a whole sub-directory, you’ll need to create a separate .htaccess file for each, and add the require code to it, as mentioned above. No more is needed, as this second .htaccess file will reference the main .htaccess that contains the protection details.

For example, if you wanted to restrict your members directory to anybody who has a username, create a new .htaccess file that will need to be placed within the members folder, and copy the following in to it.

require valid-user

You can restrict a directory in the same way as files, simply by changing the value valid-user to whichever is required (either a username or group name).

To restrict the files within the sub-directory, you can add block code as well.

Custom error page!

If a user were to enter the wrong username and password combination, or click the "cancel" button, they would be greeted by the standard "error page", which probably won’t match your web site layout, and doesn't offer the user any real assistance.

To combat this, you can create your own "error page", which in reality is just like any other web page, to provide a nicer looking error message, as well as being able to offer more help to the user, such as a link to a contact form to ask for help, or to invite them to sign up to your web site.

The code to do this will need to be placed within your .htaccess file, and is written as:

ErrorDocument 401 /401.htm

... where in this example, our custom page is 401.htm. You can use whatever file name you like, so long as you reference it correctly.

Uploading for files!

Uploading your files will be no different from uploading any other HTML, PHP, CGI file that you’ve previously done (though there may be some unexpected results once uploaded), except for the locations that some of the files need to be uploaded. A .htpasswd (and possibly a .htgroup) file won’t be uploaded in to your htdocs folder, as it might be accessible via your web site. Freeola do have protection against such a thing, but just to be sure, it should be uploaded in your root directory, next to the htdocs folder (not in it).

By contrast, the .htaccess must be uploaded within the htdocs folder or subsequent required directory within. If this isn’t done, Freeola’s servers won’t reference it when users come to your web site.

Not too many users!

If you add a lot of username and passwords to the file, you may find that your web site begins to slow down a little, so be sure to keep an eye on how your web site performs over time if you are continually adding username and password combinations.

If you get to a point where your site is becoming really slow, it’s probably time to look in to a more robust web site login option, which is unfortunately beyond this current article.

That should tide you over!

While this little article doesn’t cover every aspect of mod_auth, it should be enough for a basic username / password authentication to hide some of your web content from un-requested visitors.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

As always, any comments, questions, and especially corrections are welcome.
Tue 18/11/08 at 16:23:
Posts: 591

I'm using basic auth as here, to protect aspects of a site.

Is there a way to get browsers to fire the auth request on *each* visit?

By this, I mean that currently, once you've authenticated and for example, hit the 'back' button, then re-enter the site during the same browser session, you are not prompted for the auth again.

Hope you get the idea.

Mon 23/04/07 at 08:54:
"We are not alone!"
Posts: 34
Thank you for your reply cjh, I've successfully sussed what I done wrong.
I made the address too long and didn't post the .htaccess file in the correct directory. I initially didn't realise at 2am in the morning that I had to add the .htaccess file to the sub folder for which required protection. Thanks for all your help anyway... much appreciated!
Sun 22/04/07 at 22:41:
"It goes so quickly"
Posts: 4,104
Hello Puniksem™,

Unfortunately I don't use CuteFTP, so can't check this out directly, but are you sure that the files are uploaded / named correctly? If you're using a Windows operating system, it may have added a .txt to the end of each file name, meaning that once uploaded, the Freeola servers would not see the files as expected, and so not run your password protection as you'd want.
Sun 22/04/07 at 16:15:
"We are not alone!"
Posts: 34
Thank you very much for providing this tutorial, however I have had a couple of questions I really need answering.

I have created two documents .htpasswd and .htaccess I have filled out the two documents with the relative respective code and saved them to a folder. Then opening the folder with cuteftp, I've uploaded the files into there respetive folders root folder for .htpasswd and /HTDOCS/ for the .htacces file.

Yet the directory and/or file I attempt to secure still gets access without the password challenge.

Thank you in advance for any suggestions/remedies anyone can offer.
Fri 30/03/07 at 18:27:
Posts: 1,015
Many thanks, I found this a very useful tutorial.

Fri 30/03/07 at 15:47:
"It goes so quickly"
Posts: 4,104
Update: Added an additional section on how to include a custom error page, which appears near the end of the article.
Thu 01/03/07 at 18:43:
"It goes so quickly"
Posts: 4,104
I'm not really clued up on the DPA, but I think its things like keeping the data secure and safe, what you plan on doing with the data, who else may have access to it, and so fourth.

Basically once someone hands over their personal data, you become responsible for it, and if you fail in such responsibilities, you will be pulled up on it by (I think) the information commissioner.
Thu 01/03/07 at 14:51:
Posts: 1,015
Hi thanks for that, the band that we are doing a web site for would prefer an email being delivered to some ones in box, rather than hoping that they visit the web site.

How does the dtat protection act work, if some one gives you their email, wwhat does the law actually say? I did a search but its rather vain.

Wed 28/02/07 at 17:04:
"It goes so quickly"
Posts: 4,104
It's a possibility, though a couple of problems are:

- Currently Freeola's mail system seems to be having problems, with emails arriving quite late, which may cause problems when people complain their daily / weekly / monthly email isn't coming through.

- I only know how to do so via PHP's mail function, which if used for a larger number of email addresses can clog up the system.

- An email address is considered private data and hence would be subject to data protection laws.

So if I was going to put one together, it would most likely just be a pre-scripted PHP file(s) that a user could just install, but I'd want to do it properly, which might take a little while.

My personal tip for now would be to use a web feed.
Wed 28/02/07 at 01:49:
Posts: 1,015
how about a tutoriol on adding a mailing list to a site? have you any tips on that?

Freeola is a UK internet service provider offering the best value and extensive free services. Please compare our domain name registration prices or check out our UK high speed internet access. If you are in business please see examples of our free hosting at

Safe and Secure Payment