Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Membership Area without sessions

Status
Not open for further replies.

GDX

Programmer
Jun 4, 2000
186
US
I need to somehow come up with a way to create a membership area without the help for Sessions, I dont want to use session because of client side cookies. There is a huge problem if the client doesnt accept cookies. Does anyone know of a good way of accomplishing this? Any links/resources will be greatly appreciated.

Thank you. Gordon R. Durgha
gd@vslink.net
 
Setting a session variable (stored in the global.asa file) does not set a cookie on your client's machine...
Code:
<%
session(&quot;myVarName&quot;) = myVarValue
%>

can then be accessed later by:
Code:
<%
myVarName = session(&quot;myVarName&quot;)
%>[code]

The only problem with this would be the session timing out, and you can control that by setting the [code]session.timeout
to something other than the default 20 minutes, and encouraging the users to then hit some logout button before they exit that would destroy the session variable(s) that were created by calling the
Code:
session.abandon
method.

The only other way I have found to do some low profile data persistence is to set hidden form variables to the values that you want to persist. Then, you make navigation of the site available by a series of different 'submit' buttons that pass these variables back and forth. You can then pick them back up using
Code:
request.form(&quot;soAndSo&quot;)
. This method can make coding a nightmare, though, because inevitably you want to give users options to go several different places, and that can make for some very lengthy code that is difficult to debug.

Of the two, session variables is definitely my favorite way to go.

hope it helps!:)
Paul Prewett
 
I understand how you might not want to use Session variables, since Session variables are only available to users who have cookies enabled.

The only resolution I can think of is to have a separate logged_in table with maybe 2 fields, then query that table each time to see if the user is logged in.

The table would consist of 2 fields, username, time_logged_in. You could query this table on every page that needs to be protected. I know that this will incur additional overhead, but this might be one of the more secure ways to incorporate this. Then, when the user logs out, you can just delete that row from the database. Also, in your include file you can compare the current time with the time_logged_in, to automatically force a user logout. The best way of implementing this would definitely be by using a stored procedure to return either a true or a false.
If you are using Access, then you can just pass in the SQL like normal, but you might need to make two or three connection calls to authenticate. If you are really interested in this method, and you are using access, see if you can get the MSDE. It's like an add-on for access, making it akin to a lite version of SQL Server. You can download it at


If security isn't a big issue, then you should just pass around querystring and form variables, then in your include do a Request(&quot;formvariable&quot;). By calling Request this way, it will check both the QueryString and the Form collection, making it so you don't have to worry about where it's coming from. The downside to this is that by storing the data in either of the Request collections, all someone needs to do is hit the back button to compromise your security.

One last option that I just thought of is by creating a disassociated (or custom) recordset at the Application level. Add the fields username and logged in, then filter the recordset (much like in my database example) looking for the username. It would be extremely similar to the database example as above, but it would be stored in an Application variable. The benefit of this is that it reduces the workload on the DB Server, and also one less connection to the DB Server is needed. The downside is that if you are expecing a lot of users, that Application recordset could get real big real quick, consuming more of your web server memory and resources. If you need more information on custom recordsets, check out this link:


there are probably better ways to do this, but this is all that I could think of. I would be very interested to hear what the other members opinions are on the best way to implement this.

good luck
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top