Session Variables

[ekendricks]

I am using Frontpage 2k and MSSql 2k:

I'm using the script below to set session vairables for login. The login script uses table "EmailUser" to return the UserID of the person logging in. That Id Is used in a SQL stmt to return records from table "Obituary" for that user on the "List" page. From the "List" page there are approx six other pages that perform add, view, delete and various other functions. I'm having to pass a number of string variables, and sometimes form.variables between pages that are required in a SQL STMT on those pages. This has become cumbersome and conflicting since you can go from one page to another without having to return to the "List" page first.

My question is: Once the "List Page" has returned the list of records for the specific user, can I, how do I, set an additional set of variables based on the record that is selected by the user on the "List Page". These variables would be available until the user returns to the "List Page" and selects another record, thus updating/changing the session vairables.


<%
Response.ExpiresAbsolute = Now() - 1
Response.AddHeader "Cache-Control", "no-cache"
Dim HTTP_REFERRER, UserObject
Status = "Please log in."
HTTP_REFERRER = Request("HTTP_REFERRER")
If Request.Form("username") <> "" Then
If Login Then

' MODIFY THE SESSION VARIABLE AS REQUIRED

Set Session("UID") = UserObject


If HTTP_REFERRER = "" Then
Response.Redirect "obituarylist.asp"
Else
Response.Redirect HTTP_REFERRER
End If
Else
Status = "Invalid Login... Please Try Again."
End If
End If

Function Login
Dim conn, rs, sql, dbFIle
dbFile = "EmailUser"
Set conn = Server.CreateObject("ADODB.Connection")
conn.open ="Provider=sqloledb;Data Source=xxxx,1433;Network Library=DBMSSOCN;Initial Catalog=xxxxx;User Id=xxxxx;Password=xxxxxx;"

Set rs = Server.CreateObject("ADODB.Recordset")
sql = "SELECT * FROM EmailUser WHERE (NOT (U_Access = 0)) And U_ID = '" & Request.Form("Username") & "' AND U_Password = '" & Request.Form("Password")& "'"
rs.Open sql, conn, 3, 3
If Not rs.EOF Then
Set UserObject = CreateObject("Scripting.Dictionary")
For each field in rs.Fields
UserObject.Add field.name, field.value
Next
Login = True
Else
Login = False
End If
rs.Close
set rs = nothing
conn.Close
set conn = nothing
End Function
%>


Thanks

Ernest L.Kendricks

[Rob]

Hi Ernest...

I am suprised you are using FrontPage.... it is not the friendliest of dev environments for an ASP developer as it likes to make nice little unwelcome changes to code every now and again. ??:

Once you call the login function, I would simply grab the fields from the records you want to persist across pages, and throw them into session variables.

Session("var1") = rs("fieldname")

you can retieve those values on subsequent pages by using:-
Var1 = Session("Var1")

anyway...

I hope I have picked up correctly on what you are trying to do.

Regards,

[vor]

Front page... Arg. hehe. I'm a Homesite Kinda person.

Looks to me your making a Login type of thing.
Rob is right about just dumping some of the stuff you want in a session variable. But Sessions do time out after 20 minutes of the user being Idle.

So my sugguestion is, You call the login function and if everything is kewl, store the username and other properties about the user. Also do a session("logged") = now. You can use this to tell if the user is logged in and at the same time keep track what time the user logged in.

Then at the top of every page (use an include to save yourself some headache) call a function to check if the user is logged in and if he isn't, redirect the user to the login or some main page with a message.

The functon can be like

Code: Select all

function IsLoggedIn(returnVal)
  dim isOk
  isOk = false
  if not session("logged") = "" then isOk = true
  
  if not isOk and not returnVal then Response.Redirect("SomePlace")
  isLoggedIn = isOk
end function

This is the sort of Check Login I use. the return Value just tells the function if it should return a value, If you put it as False and the user isn't logged in, it will redirect the user. If your returnVal is True then the function will return true if logged in or false if not. I tend to write security functions like this. Cause half the time you want to redirect the user to some "no permissions, now get" page. So it serves as a duel function type of thing.

So, hope this helps any. Peace Out.

[Rob]

Hi...

That's also another way among many....

You can of course set session timeouts to whatever you like, and a user would have to be completly inactive for the entire period for it to timeout.

Vor... you may know that session variables use a cookie on the client machine (the encryption of which is publically known)...

I would never recommend storing an Isloggedin key and checking that it is greater than "" for a true result. This is probabaly the easiest thing to cirumvent.

A better way would be to encrypt the username and password using an encryption function... store the encypted username and password in their own key, and use a similar function to what you have listed above Vor, but to retreive and decrypt the password and username and to then authenticate that with the database.

Anyway, just thought people should be aware.

[vor]

Rob, actually all Session Variables live in Server Memory.. NoT inside a cookie. Sessions work by saving a cookie with a Unique Session ID that tells the server who you are and knows what session variables to access in SERVER MEMORY. So.. storing anything in a session is pretty safe since any of the data does not enter the client side.

If you have Cookies turned off, then yes Sessions wouldn't work since its unable to store a Session ID on your machine. Thats why you would check to see if Cookies are enabled.

Quote from http://builder.com.com/5100-6387-5030436.html

<blockquote id="quote"><font size="1" face="geneva, verdana, arial" id="quote">quote:<hr height="1" noshade id="quote">
Session state
Like application state, using session state involves storing information in server memory. But unlike application state, the server stores a different copy of the session variables for each browser session. The server differentiates between sessions by assigning an internal Session ID. Session IDs are unique across time, meaning that if a user on a site closes the browser, reopens it, and navigates to the same site, that user will be considered a new user and assigned a new Session ID. Using the Session ID, the server can access a unique key-value dictionary structure that stores session-specific information that persists between server round-trips and page requests
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

I've worked on many WebRelated programs. And I have only seen 2 ways of how to tell if the user is logged in. Session Variables Or Encrypted Cookies. And not a single developer I've worked with has ever said session variables are unsafe. The only unsafe thing about them is if you store to much, you'll just drain server ram. Thats why 20 minutes or less is a good timeout. Any longer for high visited sites isn't a good thing.

[Rob]

I stand corrected!!

I gave advice as if you were storing stuff in cookies...

I know session vars work differently... the session variables are of course stored with a cookie... and yes this cookie is just an ID.

I was having a thick moment...

Apologies :P

[Rob]

[xx(]

[munim]

Frontpage is certainly not a good development environment for ASP development. Most of the pages need Frontpage Server extensions... something which many hosts DON'T provide.
Try Dreamweaver MX... its really cool and programming with ASP/ASP.NET becomes really easy and fun.