Password Protecting a Page | Learn How to Program Using Any Web Browser

Truly effective password protection is, of course, impossible in a solely client-side environment. (As you probably know, the programs in this book have all been written in client-side JavaScript.) You shouldn’t regard any client-side mechanism as 100-percent secure under any conditions. Client-side password protection shouldn’t be used to store state secrets such as the access codes to the Star Wars defense system or the combination to Fort Knox.

If you think about it, in a client-side environment any kind of password protection is bound to be tricky to implement because the user can view your source code. However, if you don’t need really, really bullet-proof protection, and enough is good enough for your password scheme, then the example I’m going to show you for password protecting a page using only client-side programming works pretty well—and is quite sneaky!

The scheme uses a filename (without the .html extension) as the password. If the user doesn’t enter the password, she is never “sent” to the protected page. The password can never be viewed by opening the source code—because it doesn’t exist in code but rather as the part of a filename that comes before the file extension.

In the example, there’s one password for everybody rather than individual user name and password pairs. Although limited, this could still be useful. For example, you might want to protect your confidential business plan that has been placed on the Web but have one password to give out to various possible investors.

Try This At Home

In order to create individual name and password pairs in client-side JavaScript, you can use cookies. Cookies are tokens placed by Web applications on individual computers that the Web application can use to track computers, users, and choices made by individual users.

User names and passwords—possibly encrypted—can be stored as cookies on individual systems. Why don’t you see if you can create an application of your own using cookies?

You can find out more about programming cookies in JavaScript at WebReference.com (http://www.webreference.com/js/column8/) and elsewhere on the Web.

Advanced Note

Actually, it’d be far better to use a server-side database to store user names and passwords. Server-side processing could be done using a Common Gateway Interface (CGI) program or other server-side mechanism, such as server-side HTML generation.

Caution

When using the single-password arrangement, you must take care from a Web administration viewpoint to place the protected file in a directory that contains a file named index.html. If you don’t do this, a user could discover the contents of the directory (and the name of the supposedly password protected file) by entering the name of the directory followed by a forward slash (/).

To Password Protect a Home Page:

Create an HTML file that’s to be protected by a password. The password will be the name of the file without the .html extension. In the example, it’s named LearnToProgram.html, and the password is LearnToProgram.

Add some HTML to LearnToProgram.html, for example:

 <HTML> <HEAD> <TITLE>  Learn to Program  </TITLE> <HEAD> <BODY> <H1>  You made it: You're in like Flynn.  </H1> </BODY> </HTML>

Create a new HTML page in the same directory as LearnToProgram.html. This access page will be used to password protect LearnToProgram.html. You’ll give out the URL to this access page.

Create an HTML skeleton within the access page:

 <HTML> <HEAD> <TITLE>     Test that password     </TITLE> </HEAD> <BODY>  ...  </BODY> </HTML>

At the top of the <BODY> section of the page, add beginning and ending <SCRIPT> tags:
```
 <BODY> <SCRIPT> </SCRIPT> </BODY> 
```
At the beginning of the script block, declare a password variable and assign an empty string to it:
```
 <SCRIPT>  var password = ""; 
```

Prompt the user for the password:

 password=prompt("Please enter your password!","");

If the user entered a password, use the href property of the browser’s location object to go to the file named in the password variable plus the .html file extension:
```
 if (password != null) {     location.href= password + ".html";  } 
```
Of course, this will only succeed in opening a file if a file named in the password variable plus .html exists in the current directory.

Save the access page (you can find the complete source code for the page in Listing 11-1).

Listing 11.1: Password Protecting a Page

 <HTML> <HEAD> <TITLE>  Test that password  </TITLE> </HEAD> <BODY> <SCRIPT>  var password = "";  password=prompt("Please enter your password!","");  if (password != null) {     location.href= password + ".html";  }  </SCRIPT> </BODY> </HTML>

Open the access page in a browser. A prompt box will appear (see Figure 11-1).

Figure 11-1: The user enters the password in a prompt box.
Enter a phony password—such as Bogus —in the prompt box.
Click OK. It’s possible (but unlikely) that the file thus specified exists in the current directory serving HTML, in which case Bogus.html will open. More likely, it doesn’t—in which case the server will generate an HTTP 404 “File not found” error. The resulting page served to the user will depend on the Web server and browser; most likely it will appear as shown Figure 11-2, but a blank screen is also a possible result.

Figure 11-2: If the file pointed to by the password input isn’t found, an HTTP 404 error is generated.
Open the access page again and enter the right password (see Figure 11-3).

Figure 11-3: The password is LearnToProgram.
Click OK. The protected page will open (see Figure 11-4).

Figure 11-4: When the password (the name of the destination page) is correctly entered, the page will open.

Problems with This Password Scheme

I’ve mentioned quite a few problems with this password scheme if intended to protect pages that must be truly secure. Here’s a summary of these problems:

Client-side password protection should never be regarded as completely secure because users can view the source code used to create the clientside document.
A file named index.html must be located in the directory containing the protected file, or any user can view directory information (including the name of the protected file).
It’s best to use cookies to provide individualized user logins and passwords.
A better scheme is to use server-side processing and a database to manage user information and passwords.
A table and form arrangement can be used to receive passwords rather than the prompt box shown in the example.