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" <anonymous@devdex.com> wrote in message
news:uAZQpuC3EHA.924@TK2MSFTNGP14.phx.gbl...[color=blue]
>
>
> 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.
>
>
>
> *** Sent via Developersdex
http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it![/color]
