Cookie Based Login

In This Site

In This Section

Take Your Web Site to New Levels

Using a Cookie to Secure Your Website

Using a cookie to hold your registration details offers a flexible way to keep track of users as they move through your website. You can keep track of a large number of parameters in addition to login details. You can place information on product selections, user preferences, and even the length of time since their last visit.

In this example, we'll use a cookie to store the UserID field from your registration database. This will allow any other page on your site to read the registration cookie. You can then choose to restrict access to individual pages OR specific data by checking for the existence of the cookie and comparing its value to the UserID field in your database.

This technique involves a login page that creates a cookie called "UserID" that stores the UserID value from your registration table.

Each page in the secure section of the website will have code that will check to see if the UserID cookie exists and if it does not, the user will be redirected to the login page.

For pages that need to access the database using the Database Results Wizard (DRW), we'll add some code that will take the cookie value and add it to the query string at the end of the url. This will make it available to the DRW just as if you had passed the page using methods that you learned in our tutorial Passing Parameters.

Limitations of this technique

Using a cookie based login will only work if your user has cookies enabled on their computer. In the past, some people feared cookies, believing that they were a potential security leak. This belief is false. They are a simple text file that can only be read by the website that creates them. Other people believed that cookies removed the anonymity from browsing the Internet by allowing websites to track your movements.

The reality today is that most sites use cookies. Sites including Google, Yahoo and even Microsoft use cookies. They are a key tool in maintaining state on the Internet.

The good news is that cookies are enabled by default in most browsers. This means that the vast majority of users CAN accept your cookies. Unfortunately visitors that refuse cookies will not be able to use your site.

First, let's create the Registration Database

This technique relies on the use of a database to hold the registration information. It does not need to be complex. It can contain as little as one table that will contain login information. Call the table Registration and place the fields you would like to track. If you are allowing users to register themselves, you can add a registration page that will collect the information and post to the database. Be sure to include as a minimum the following fields:

UserID (autonumber field) as the key field for the table
Account_Username to hold the username
Account_Password to hold their password
PasswordHint to be used if they forget their password
Email to be used for communication AND for retrieving lost login information

You can also add a field to your registration database to specify access level (i.e. Admin=1, Contributor=2, Browser=3 and so on).

Create the Welcome Page

Once your users login, they will be directed to the first page in your protected section of the website. Here, we'll create the cookie so that subsequent pages will be able to remember your UserID and provide secure access.

On your welcome page, select Insert-Database-Results. Choose your registration database as the connection and your registration form as the Record Source. Include the following fields in your DRW, Account_Username, Account_Password, UserID and FirstName.

In Step 3, select More Options and Criteria. Set the DRW to require Account_Username=Account_Username and Account_Password=Account_Password. This will make sure that your records are limited to only the registration record that matches the username and password entered into the registration form.

If you want to limit access to users of a specific access level then set a third criteria such as AccessLevel=1. This will return records only if they have the correct level of access (set in the Registration Table).

Also in the More Options section type the following into the Message To Display of No Records Are Returned:

Please return to the login page and login using a valid username and password. If you are not sure of your login information, please click the Lost Your Password link.

This message will provide directions to users that have not yet logged in.

In Step 4 select List - one record per item and deselect the label option.

In Step 5, display all the records together and deselect the search option. Your DRW will now resemble the following:

This will display the four fields for the currently logged in user. I recommend changing this to something a little more personal such as:

Welcome <<FirstName>>, you now have access to the site.

You can delete the field values that you don't wish to display.

Ok, now comes the FrontPage Magic. Click on the field name <<FirstName>> and then switch to HTML view. You'll see a large section of highlighted code. You need to insert a small code snippet immediately to the right of this highlighted code. Type the following code:

<%
Response.Cookies("Login")("UserID")=cStr(fp_rs("UserID"))
Response.Cookies("Login").Expires =Date+365
%>

This will create a Cookie called Login with a key called UserID that will be equal to the value of the UserID field in your database. It also sets the expiry date of the cookie to one year from the current date. Without an expiry the cookie will not be saved to your hard drive and will thus expire at the end of your current session. It is this cookie that will allow us to maintain a record of the current user as they move through the database.

Save the file as welcome.asp. You are now ready to create your login page.

Create the login page

On a blank page, add a form for your login page. Place two fields, Account_Username and Account_Password onto the form. Set the form properties as Send To Other and set welcome.asp as the action. This will post the login information to your welcome page.

Secure pages using your UserID

It is a simple matter to protect pages to only those users with acceptable UserIDs. Since only a valid login will create the cookie, then all we need to do is place a little bit of code at the top of our protected pages to check to see if the cookie exists. If it does not, then redirect them to the login page. Here is the code:

<%
If Request.Cookies("Login")("UserID")="" _
Then Response.Redirect "login.asp"
If Request("UserID")="" Then Response.Redirect _
Request.ServerVariables("SCRIPT_NAME") & "?" & _
Request.Cookies("Login")
If Request.Cookies("Login")("UserID") <> Request("UserID") _
Then Response.Redirect "login.asp"
%>

The underscore character _ indicates where I've continued a single line of code onto the following line. If you wish, you can delete the underscore and place the code onto a single line.

This code does three things. The first If statement checks to see if the "UserID" cookie exists. If it doesn't, the user will be redirected to the login page.

The second If statement looks to see if the "UserID" field is available and if not, reloads the page and adds the cookie keys to the query string. This will make them available for use in the database results wizard.

The third If statement prevents users from hacking the page. Once a user has seen their UserID added to the hyperlink query they might try to hack the database by manually changing the UserID value at the end of the query string. For instance, if they change their browser address from::

http://lFrontPageMagic.com/security/login/test.asp?UserID=1

to:

http://lFrontPageMagic.com/security/login/test.asp?UserID=3

the statement will compare the value of the UserID key to the value in the query string. If they don't match, the user will be redirected to the login page. This offers a moderate level of hacker control.

Limit access to specific users only

If you want to ensure that only a limited number of users have access to the page, you need to change the code only slightly.

<%
If Request.Cookies("Login")("UserID") <> "1" _
OR Request.Cookies("Login")("UserID") <> "2" _
Then Response.Redirect "login.asp"
If Request("UserID")="" Then Response.Redirect _
Request.ServerVariables("SCRIPT_NAME") & "?" & _
Request.Cookies("Login")
If Request.Cookies("Login")("UserID") <> Request("UserID") _
Then Response.Redirect "login.asp"
%>

The above code will redirect any users whose UserID is not equal to 1 or 2. This way, only your selected users will have access to the page.

Protect Your Data

Your data is also protected. If you want a user to see only the data that they have a right to see, you need to set your query to something like the following:

SELECT * FROM TableName WHERE UserID=::UserID::

Or in your DRW set the Criteria to UserID=[UserID]. Your criteria screen should look like the following:

This login technique can be modified to track more complex sites with numerous pieces of data that must be tracked. For instance, you may need to track their UserID as they login, and then keep track of an OrderID as they place an order on your site. On my site www.MountainNature.com, I created a sightings database that began with a login screen. Users then filled out a form to describe the details of a trip they had taken and a TripID cookie key was added to the login cookie. Once they created a trip record they would add individual plant, animal and bird sightings to the trip. Each of these would add a PlantID, AnimalID and BirdID key to the cookie. No matter where they move on the site, the sightings database can remember their last choice and make the site operate more smoothly - and this makes them happier.

And all it took was a little FrontPage Magic.

These tutorials are part of an upcoming training course called "FrontPage Magic - How To Create A Database Driven Website For Non-Programmers". Stay tuned for more details on this exciting new product.