(This article assumes the reader is familiar with ASP development including record sets, query strings, and session variables.)

I have developed several Intranets and Extranets which require password entry membership validation. Throughout the duration of a user's visit, I may need to know several things about the user in order to continue to grant him/her access to other pages.

ASP has built-in Session objects which keep track of this quite nicely. However, the use of these objects depend on requiring the user to have cookies turned on in his/her browser. What happens if a client requires you to create a cookieless ASP application? How can you track the user's session from page to page? I'll show you how with a couple of simple include files.

First you'll need to decide what values you need to track from page to page. In this example, I have chosen to track only seven values.

When the user initially logs into your site, s/he is using a Form. The Form submission process passes the values entered to the "action=" page. Assume we have an HTML form field called "Alias" for keeping track of the user login name. You can retrieve the value entered into the Alias field by using Request.form("Alias"). However, how do you continue to pass the Alias value from page to page without a form on each page? This is where my include files and query strings come in handy.

Once the user has logged in with the alias and password, you use the Request.form("Alias") and Request.form("Password") field values to look up the record in your database table. If the search is successful, you then populate local variables from the database record set object like so:

   SessionID = rs("alias") 
   SessionType = rs("type")
   SessionLookup = SessionID
   SessionSplit = rs("splitscreen")   
   SessionCtr = rs("counter")
   SessionPost = ""
   SessionSQL = ""

   <!--#include file="../include/sendvars.asp" -->

<% 
sendvars = _
   "?ID=" & SessionID & _
   "&TYPE=" & SessionType & _
   "&POST=" & SessionPost & _
   "&SPLIT=" & SessionSplit & _
   "&CTR=" & SessionCtr & _
   "&LOOK=" & SessionLookup & _
   "&CMD=" & Replace(SessionSQL," ", "%20")
%>

<!--#include file="../include/getvars.asp" -->

<%  
SessionID = Request("ID") 
SessionType = Request("TYPE")
SessionPost = Request("POST")

if Request("SPLIT") <> "" then
   SessionSplit = Int(Request("SPLIT"))
else
   SessionSplit = 0 
end if

if Request("CTR") <> "" then
   SessionCtr = Int(Request("CTR"))
else
   SessionCtr = 0 
end if
SessionLookup = Request("LOOK")
SessionSQL = Replace(Request("CMD"),"%20", " ") 
%>
<!--#include file="../include/sendvars.asp" -->

• Storing the local variable
• Passing it to the next URL in the query string
• Retrieving it from the query string
• Manipulating it as needed
• Passing it to the next URL in the query string
• and so on...

For each link contained on your site, you need to add the query string, as shown below.

<a href="/jw/menu/mainmenu.asp<%=sendvars%>">Main Menu</a><br>

<!--#include file="../include/getvars.asp" -->

For instance, on one of my pages, I had two links which required different query strings. In order to alter the query strings, I changed the needed variable, and again called the include file to repopulate the "sendvars" query string value. As an example, in the below code, I want to call the same asp page, but I want to pass an "R" if the user is posting a resume, and a "J" if the user intends to post a job. After I change the SessionPost value, I again populate the query string via the sendvars.asp file, and then create my hyperlink tag.

<%SessionPost = "R" %>
<!--#include file="../include/sendvars.asp" -->
      <a href="/jw/post/post_add.asp<%=sendvars%>">
      Post a New Resume</a><br>

<%SessionPost = "J" %>
<!--#include file="../include/sendvars.asp" -->
      <a href="/jw/post/post_add.asp<%=sendvars%>">
      Post a New Job</a><br>

This method does not allow for security however, because the user could tamper with the data being passed and override the values you populated from the table. You could make this more secure by passing the alias and password on each page. One drawback is that this would display the user's password for any bypassers to see. Also, you would then have to look up the alias and password in the database each time you allowed the user to view or save secure information -- a method which would cost in performance.

IE 4.0 and IE 5.0 have some cool new features, beyond the scope of this article, for tracking sessions, however these are browser dependent and I don't think the general public is ready for a complete IE 5.0 driven web site this year.

So in conclusion, I'll stick to using Session variables to control my nondurable state and databases to store my durable state.