To read the article online, visit http://www.4GuysFromRolla.com/webtech/050499-1.shtml

Simple Authentication


For More Information...
For more information on authenticating users, check out the Authentication Article Index. To learn more about securing data and your Web site, check out the Security Article Index.

Authentication is the process of allowing only valid (or authenticated) web visitors to view your web pages. Why would you want to authenticate, you might ask? Perhaps you might want users to submit some personal information before browsing your site, or perhaps you might have sensitive information that you want accessible to only selected members. Maybe you have written some remote administration scripts, and you want to be the only person who can run them! There are an innumerous amount of reasons why a web site might need to let only a certain set of folks view their pages. This article intends to inform you how to implement such as system!

There are many ways to authenticate visitors. You can use IIS settings, cookies, or third party components. This article will discuss using cookies (Session variables) to authenticate web users!

The logic behind authentication using Session variables is fairly straightforward. We will create a session variable that will be a boolean. This variable we'll call bolAuthenticated and will be True if the user has been authenticated and false if the user hasn't.

The variable will be created an initialized in Global.asa. (To learn more about global.asa, please read Everything you wanted to know about Global.asa but were afraid to ask!) Add the initialization of the variable to the Session_OnStart function:

Sub Session_OnStart
    ...
    Session("bolAuthenticated") = False
    ...
End Sub

This will create and initialize the bolAuthenticated variable for each user entering our site. Now, at the top of all of our ASP pages that we want viewable only by authenticated users, we need to add the following lines of code:

If Session("bolAuthenticated") = False Then
   Response.Redirect "/authenticate.asp?" & Server.URLEncode(Request.ServerVariables("SCRIPT_NAME"))
End If

This if statement must appear before any HTML content (that means before any Response.Write's!) because the redirect needs to preceed all HTML content. What this will do, is if the user has not been authenticated, it will send him/her to authenticate.asp (located in the root web directory) for them to be authenticated. The current page's URL is passed along so once the user is authenticated, they can be automatically sent back to this page! (For more information on Request.ServerVariables, read Using the Request.ServerVariables Object; for information on using the Server.UrlEncode method check out: Using Server.URLEncode.)

In our file, authenticate.asp, we will need to collect user information and pass it onto a validating page, along with the original URL. A database of acceptable users will need to be maintained, perhaps with username and password. For this example, I will craft authenticate.asp so that it creates a form that passes along the passed in URL and the user's name/password to validate.asp.

Authenticate.asp:
<%
'Get the URL from the querystring
Dim URL
URL = Request.QueryString
%>

<HTML>
<BODY>
<FORM METHOD=POST ACTION="/validate.asp">
   <!-- Store the URL in a hidden variable -->
   <INPUT TYPE=HIDDEN NAME="URL" VALUE="<%=URL%>">

   User Name:
   <INPUT TYPE=TEXT NAME="txtName">

   Password:
   <INPUT TYPE=PASSWORD NAME="txtPassword">

   <INPUT TYPE=SUBMIT>
</FORM>
</BODY>
</HTML>

That's it! Now, validate.asp must take the information passed in and check to see if the username/password combination exists in the database. I will assume that the database table that stores valid users is very simple in design (I'd recommend a more robust design, but for this example, a simplistic design will do). Here's the design I'll be using for this example:

ValidUsers
UserNameText
PasswordText

(If this were an Access database, for security reasons you'd want the database located on a non-web-accessible directory, and use a System DSN to access it (otherwise someone could download the .mdb file and view the database!).) Keeping this data design in mind, let's look at what validate.asp would need to look like. I will use mostly comments/pseudocode for validate.asp, and leave the details up to you (since they will differ if your data design does...)

Validate.asp:
<%
'Read in the password and username from the form
Dim strUserName, strPassword
strUserName = Request.form("txtName")
strPassword = Request.form("txtPassword")

'Establish a database connection...

'Run your SQL query
Dim strSQL
strSQL = "SELECT * FROM ValidUsers WHERE UserName = " & _
     strUserName & " AND Password = " & _
     strPassword

'Run the query... (Conn is the name of the database connection)
Dim rs
Set rs = Conn.Execute(strSQL)

'If the recordset is not empty, the user is validated
If Not rs.EOF Then
     'We need to set bolAuthenticated as True!
     Session("bolAuthenticated") = True

     'Send the user to the URL they came from
     Response.Redirect Request.form("URL")
Else
     'The user was not validated...
     'Take them to a page which tells them they were not validated...
     Response.Redirect "/notvalidated.asp
End If

%>

That's it! You can add other features, check for other criteria, if you'd like. The logic is, in my opinion, fairly straight forward. The user has been authenticated and now can view any page (since bolAutheitcated was set to true). It's a fairly straight forward implementation.

There are some drawbacks to the cookie method discussed in this article. First, users who have cookies disabled will not be able to be authenticated. This means that they will not be able to view any of your restricted pages, even if they enter valid credentials in authenticate.asp. This is a minor issue, though, for the vast majority of web surfers today do have cookies enabled. Another issue using cookies is not foolproof to those who want to bypass your authentication. Only very savvy hackers will be able to get past your authentication, but if it is imperative that your data not be seen by anyone who is not authenticated, then the model above is not the best.

There are advantages, though! It's easy to set up and easy to understand!

For more information on Authentication, I highly recommend Authentication Overview at ActiveServerPages.com.

Happy Programming!


Article Information
Article Title: Simple Authentication
Article Author: Scott Mitchell
Published Date: Tuesday, May 04, 1999
Article URL: http://www.4GuysFromRolla.com/webtech/050499-1.shtml


Copyright 2014 QuinStreet Inc. All Rights Reserved.
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers