Unlimited Session.TimeOut

[cumap]

Hi, I'm looking for a way to NEVER expired logon user(s) until they log out or close the page themselves.

In my header, I have

Session.Timeout=1440

and also, in my global.asa, I included

Sub Session_OnStart
Session.Timeout = 1440
Session("Start") = Now
Application.Lock
...
End Sub

But, even my session seem to last longer, the server still logged me out eventually (much less than the 1440 I set). Is there something else I can do to to make this work?

thanks!

 

[guitarzan]

I don't know about having a session "never expire", I don't think you can do this, but I am not sure. But in IIS there are default timeout settings that you can set.

In IIS6, right-click over the site, select "Properties", go to "Home Directory" tab, then "Configuration" button, then "Options" tab, and change the "Session timeout" value.

You can do the same to the root "Websites" folder, to change the timeout for all sites.

 

[ChrisHirst]

You CANNOT and SHOULD NOT set sessions to never expire, you will "hang" the server.

Not every session will be closed by the user. Assuming you kill sessions on logout of course.

A browser crash or using the close button will leave sessions hanging, complete with all the resources that session has opened or is using.

Sessions are not closed when the browser closes.
Search engine crawlers open a new session on EVERY request they make to the server, but do not close them. That could be several hundreds of sessions opened per day and NEVER closed on a well crawled website.

If you want users to stay logged in use a flag in a non-expiring cookie to maintain state between visits.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[Commodore640]

So you can just keep your default session settings. If you want to keep your users in for a very long time, I would suggest my method of using cookies to relogin them back if the session is killed. Take a look at my post (right by yours). The idea is that once they log in, their log in info will be stored in an encrypted cookie on their machines as well as in session variables. If the program detects that session variables are gone, it checks if there is anything in the cookie left. If so, it decrypts the passwords and id, relogins the user and continues the process where it was broken...

BUT, it is very important to know that if you store passwords in a cookie, that can be a big security hole. Even if you use some kind of encrypton method, since they are out of the server, they can be manipulated, decrypted, and be sent back to the server, so you really have to know what you are doing. In an intranet site where only office computers are used you are pretty safe, but other than that watch out for the worst...

 

[ChrisHirst]

You should never need to store passwords in a cookie. The username, a "loggedin" flag and a hash of the "last logged in time" to check against the database entry of the same data stored as a time field so it can be hashed and checked "on the fly" should be sufficient for most systems.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum