infinite session timeout

[Joe Abou Jaoude]

hi,

I have a web app with forms authentication and a timeout session of 20
mins for security reasons. I recently added a feature that allows users
(if they want to) to automatically log in (without entering username and
password) using the cookies. Now in this case the 20 mins session
timeout has no meaning anymore so I m thinking to make the timeout
infinite in this case only.

my question is, if i do this, and then a user used the application and
closed the browser , does the server knows that this session is no
longer needed and removes it from memory even if the timeout is infinite
?

 

[Ollie]

why have any security if you do this?

 

[William F. Robertson, Jr.]

No, the server does not not about a user that has closed their browser and
will remain in memory. Worse yet, if you have a user that logs in then
closes their browser, then logs in again, you know will have two sessions on
your machine. You can see how this can quickly fill up your machine's RAM.

You should keep the timeout. You seem to want to have the user not log on
every time they come to your site. I am assuming you are using forms
authentication?

With forms authentication you have a login page defined. On the page_load
for the login page, you should just check for the cookie, validate the user,
set up their information(?), then redirect them to the page they were trying
to hit. Basically you have the btnLogin_Click code, also in the page_load
that processes the cookie.

It will be somewhat transparent for your users when their session does
timeout.

Would this solution work for you?

bill

 

[Aidan Marcuss]

Hi Joe,

The browser in now way signals the server when it is closed. You can
implement functionality in one of the client-side DHTML event
(onbeforeunload), to signal the web server (via a web service or
standard web request).

I don't quite understand your original statement, however, about the
session timeout having no meaning now that the user doesn't have to log
in. Session and Authentication cookies are two separate things. If
session expires while the user is still "authenticated", a new session
will automatically be created for them. If you want to keep that
session around for as long as they are actively using the site, you
might consider implementing some functionality in the browser to "ping"
the web server. Every request will restart the session timeout (as long
as it is a sliding timeout), but if a user may sit on one page for a
long time, you could consider using the setTimeout JScript method to
call a method every so often that calls a web service or fire a simple
page request in the background - both of which have the effect of
keeping the timeout from expiring.

Obviously there are many details I've glossed over, but I hope this
helps.

Aidan

 

[Aidan Marcuss]

Hi Joe,

The browser in now way signals the server when it is closed. You can
implement functionality in one of the client-side DHTML event
(onbeforeunload), to signal the web server (via a web service or
standard web request).

I don't quite understand your original statement, however, about the
session timeout having no meaning now that the user doesn't have to log
in. Session and Authentication cookies are two separate things. If
session expires while the user is still "authenticated", a new session
will automatically be created for them. If you want to keep that
session around for as long as they are actively using the site, you
might consider implementing some functionality in the browser to "ping"
the web server. Every request will restart the session timeout (as long
as it is a sliding timeout), but if a user may sit on one page for a
long time, you could consider using the setTimeout JScript method to
call a method every so often that calls a web service or fire a simple
page request in the background - both of which have the effect of
keeping the timeout from expiring.

Obviously there are many details I've glossed over, but I hope this
helps.

Aidan

 

[Aidan Marcuss]

Hi Joe,

The browser in now way signals the server when it is closed. You can
implement functionality in one of the client-side DHTML event
(onbeforeunload), to signal the web server (via a web service or
standard web request).

I don't quite understand your original statement, however, about the
session timeout having no meaning now that the user doesn't have to log
in. Session and Authentication cookies are two separate things. If
session expires while the user is still "authenticated", a new session
will automatically be created for them. If you want to keep that
session around for as long as they are actively using the site, you
might consider implementing some functionality in the browser to "ping"
the web server. Every request will restart the session timeout (as long
as it is a sliding timeout), but if a user may sit on one page for a
long time, you could consider using the setTimeout JScript method to
call a method every so often that calls a web service or fire a simple
page request in the background - both of which have the effect of
keeping the timeout from expiring.

Obviously there are many details I've glossed over, but I hope this
helps.

Aidan

 

[Joe Abou Jaoude]

thank u all, so it's obvious that infinite session timeout is a very
very bad idea, and well the scenario explained by William F. Robertson
is exactly the scenario that i was affraid of.

a question for Aidan Marcuss:
i thought that the session timeout is always sliding. isn't that right ?
and if no how can i do that?

it seems that i wasn't very clear in my explanation before:

1- I m using form validation (username and passwords are in a database)

2- I use sessions not only to keep track of the user but also to save
info and variables required for the web app.
and the session timeout was 20 mins
and all was fine.

Now the client wanted to add a feature where the user can login
automatically (if he wants to).

so:
1- i used cookies to recognise users and the automatic login was
accomplished succesfully.

2- originaly the session timeout was designed for security reasons (at
least this is what i think), i.e if a user forgot the browser open the
session timeout will disallow another person to enter the site from the
browser.

3-this session timeout is no longer needed since anyone can logon
automatically to the site if a user cookie resides in the client
computer.

4- the sessions are used to save sql statements and other variables, and
the timeout session will reset those variables and all the work of the
user will be lost, this is why I was thinking to have infinite timeout
session

5- Finally, based on the replies, i think the better solution is to make
the session timeout longer for user authenticated automatically ( an
hour, a day...) but not to use an infinite timeout.

 

[William F. Robertson, Jr.]

Joe,

I am not sure how involved you want to get with this, but here is a possible
solution for you.

You could easily declare a couple static methods called.

public static void SaveUserInformation( string key, object data );
public static object GetUserInformation( string key );

These methods will satisfy the requirements for number 4.

When the SaveUserInformation(...) is called, you could look determine if the
user has the "auto logon cookie". If they do not have the autologin cookie,
you will save the information in Session through the
System.Web.HttpContext.Current.Session property. If they are one of the
"auto logon" people, you could save this information in Application. Here
is some psuedo code.

public static void SaveUserInformation( string key, object data )
{
if ( PersistUserData() )
{
System.Web.HttpContext.Current.Application.Lock();
System.Web.HttpContext.Current.Application["Auto_" + key] = data;
System.Web.HttpContext.Current.Application.UnLock();
}
else
{
System.Web.HttpContext.Current.Session["Auto_" + key] = data;
}
}

The Application.Lock() method doesn't scale very well so you might want to
look towards you own static (or singleton) object to handle all the user
information (req 4).

The GetUserInformation(...) would just be the inverse of this operation.
The code will appear seamless to the page developer as it doesn't matter
whether the information is stored in session or persisted in Application.

HTH,

bill

 

[Joe Abou Jaoude]

ok, saving in application instead of session is a good idea. It might be
a good work around for the problem however it could have some memory
drawback.I'll have to look at it closely. thx.