Logging In Using ASP - Access2000

Preparing Your Development Environment

Before you can start storing passwords or creating a login page, you need a solid foundation. Begin by installing the Personal Web Server (PWS) on your local machine if you haven’t already. PWS is a lightweight ASP host that lets you test pages right on Windows without a full IIS installation. Once PWS is running, you’ll have a built‑in web server listening on port 80, ready to serve .asp files from a directory you choose.

With the server in place, the next step is to create a database that will hold user credentials. In this example we’ll use Microsoft Access 2000, which is easy to manage and integrates nicely with classic ASP. Open the Access application and create a new database called customers.mdb. Inside this database, design a table named Users (or Customers if you prefer). Add the following fields:

• Email (Short Text, Primary Key)
• PasswordHash (Text, 255 characters)
• FullName (Short Text, 255 characters)
• CreatedOn (Date/Time)

  When the table is ready, fill it with a sample record. This will give you a working baseline when you later test the login routine. Note that the password field should never store plain text. Instead, you’ll store a hash that’s derived from the user’s password. Even though the article focuses on the mechanics of logging in, keep security in mind as you move forward.

  After creating the database, you must expose it to ASP code by setting up a Data Source Name (DSN). The DSN tells your ASP script how to locate and connect to the Access file. Open Control Panel, find the “ODBC Data Sources (32‑bit)” icon, and launch it. Switch to the System DSN tab, then click Add. Choose the “Microsoft Access Driver (*.mdb)” from the list, and click Finish.

  In the dialog that follows, type a recognizable name for the DSN - something like customersDSN. Click the Select button, navigate to where you stored the customers.mdb file, and pick it. Click OK through the remaining dialogs and you’ll have a DSN ready to use.

  With the DSN in place, the final step for this section is to create a small include file that sets up session variables and optionally stores them in cookies. This file, sessions.inc, will be referenced on every page that needs user context. In its simplest form, it looks like this:

  Prompt

  <code> <p>' Initialize session if not already set</p> <p>If Session("UserEmail") = "" Then</p> <p> Session("UserEmail") = ""</p> <p> Session("UserName") = ""</p> <p>End If</p></p> <p>By keeping session initialization in a single include, you avoid duplication and make it easier to update session handling in the future. You’ll reference this include in both the registration and login pages, as well as any protected area of your site.</p> <p>Now your environment is ready: you have a local ASP server, an Access database with a DSN, and a foundational session script. The next phase is to build the actual login flow that captures user credentials, validates them, and remembers the user across pages.</p><h2>Building the Login System</h2> <p>With the groundwork laid, it’s time to craft the user experience. The core of the login system consists of three parts: a form that collects credentials, a server‑side script that stores or verifies those credentials, and a check that gates protected content. Throughout, we’ll keep the code simple enough to follow, yet robust enough for real‑world use.</p> <p>The first piece is the login form. Place this code on any page where you want users to log in, for example, <strong>login.asp</strong>. The form uses POST to submit to <strong>processLogin.asp</strong>, the script that will handle authentication.</p></p></p> <pre> <code> <form method="post" action="processLogin.asp" name="loginForm" onsubmit="return validateLogin()'> <label for="email'>Email:</label> <input type="text" name="email" id="email' required /> <br /> <label for="pwd'>Password:</label> <input type="password" name="pwd" id="pwd' required /> <br /> </p> <p>Before the form is sent to the server, we run a quick client‑side check. While server‑side validation is mandatory, client‑side validation saves bandwidth and provides instant feedback. The JavaScript function, placed in the page header, ensures both fields are non‑empty and that the email looks like an address.</p></p></p> <pre>

  Once the user clicks submit, the browser posts the data to processLogin.asp. That script opens a connection to the Access database using the DSN created earlier, looks up the provided email, and compares the submitted password to the stored hash. To keep the example straightforward, we’ll hash using the built‑in MD5 function, although for production you should consider stronger algorithms and salting.

  Prompt

  <code> <p>' Retrieve POSTed values</p> <p>Dim email, pwd</p> <p>email = Trim(Request.Form("email"))</p> <p>pwd = Trim(Request.Form("pwd"))</p> <p>' Hash the incoming password</p> <p>Dim hashedPwd</p> <p>hashedPwd = MD5(pwd) ' MD5 is available in classic ASP or via a custom function</p> <p>' Open database</p> <p>Dim conn, rs</p> <p>Set conn = Server.CreateObject("ADODB.Connection")</p> <p>conn.Open "DSN=customersDSN"</p> <p>' Query user</p> <p>Set rs = Server.CreateObject("ADODB.Recordset")</p> <p>rs.Open "SELECT * FROM Users WHERE Email = '" & email & "'", conn, 1, 3</p> <p>If Not rs.EOF Then</p> <p> ' User exists; verify password</p> <p> If rs("PasswordHash") = hashedPwd Then</p> <p> ' Successful login</p> <p> Session("UserEmail") = email</p> <p> Session("UserName") = rs("FullName")</p> <p> Response.Redirect "welcome.asp"</p> <p> Else</p> <p> ' Password mismatch</p> <p> Response.Write "Incorrect password. <a href='login.asp'>Try again</a>"</p> <p> End If</p> <p>Else</p> <p> ' No such user</p> <p> Response.Write "No account found with that email. <a href='login.asp'>Try again</a>"</p> <p>End If</p> <p>' Clean up</p> <p>rs.Close</p> <p>conn.Close</p> <p>Set rs = Nothing</p> <p>Set conn = Nothing</p> <p>%> </p> <p>Notice how the script stores the email and name in session variables. These variables persist across pages as long as the session remains active. That means any page can check <strong>Session("UserEmail")</strong> to determine whether the user is logged in.</p> <p>Next, create a simple protected page, such as <strong>welcome.asp</strong>. The top of this page includes the session script and verifies the user’s presence. If the session variable is empty, the page redirects to the login form; otherwise it greets the user.</p></p></p> <pre> <code> <p> Response.Redirect "login.asp"</p> <p>End If</p> <p>%></p><h1>Welcome, !</h1> <p>You have successfully logged in.</p> <a href="logout.asp'>Log Out

  The logout page is straightforward: it clears the session and redirects to the login form or home page.

  
  
  
  Session.Abandon
  Response.Redirect "login.asp"
  %>
  
  With these scripts in place, you have a functional login flow: users submit credentials, ASP verifies them against the Access database, stores the login state in a session, and gates protected content. The approach keeps the codebase tidy by separating concerns - database access, session handling, form validation - and demonstrates how classic ASP can work with an Access back‑end to deliver a user‑authenticating web experience.