Last post Apr 29, 2009 05:20 PM by andieje
Apr 19, 2009 01:13 AM|andieje|LINK
Lets say hypothetically a user's session timeout was a lot longer than the FormsAuthentication login timeout. If the user's login timed out and the user was redirected to the login page then the session information would still be intact. I am presuming
the forms auth module would not do anything to reset the session behaviour as this could be unwanted behaviour.
In this scenario when a user has been redirected to the login page you need to manually set up a new session for the user. How and where would you do this? Lets say you store information about the user in the session state such as their name. I am presuming
then that after the user has logged in you would call session.abandon and start a new session for the user and store their personal details in the new session. Is this right or would you do something else?
Apr 19, 2009 03:52 AM|Paul W Johnston|LINK
There is no need to reset the session, and in fact I think this would undesirable. Why would you want to reset the user's session when they reauthenticate?
Apr 19, 2009 04:23 PM|andieje|LINK
Good point! Acutally i didn't word my question very well. I was trying to think of ways to make sure my session variables never expire during a user login session. Could you simply make your session timeout a really really large value so that they would
never expire in practice unless the user didn't visit your site for months. This approach seems too simple to work and like there will be soem obvious caveat I havent spotted. If the session did timeout because the user hasn't visited the site for months you
could repopulate the session in the session_start event in global.asax after the user had logged in again
if user is authenticated
Would this work? Presumably if the users login timed out and they logged in again the Session_start event wouldnt be called and the previous session would persist. Perhaps there is a better way to handle things than this. This must be a common problem so
I am sure there must be an established solution.
Apr 20, 2009 01:04 AM|Paul W Johnston|LINK
A session that is persisted for months is not a desirable solution becuase it would scale horribly if sessios were managed in process. The use of UserProfiles would be better to store this sort of "long term" information.
Apr 20, 2009 01:30 AM|malcolms|LINK
Another option would be to store just the unique identifier for the user in the session and lookup the rest of the information from, say a database.
Apr 20, 2009 12:37 PM|andieje|LINK
Hi I don't need the information to be long term as such. That was just a possible solution I was toying with. All i want to do is to make sure that my session variables do not expire while the user is logged in. All I store in the session variables is the
user's name and id. How would you handle that?
Apr 20, 2009 12:52 PM|malcolms|LINK
Because you're using forms authentication the scenario is a little harder. I wont advise having a session where the timeout is a large amount. That defeats the purpose of the session, but you could increase both the forms authentication time out and session
The nature of the session is to persist data for a short period of time then dispose of it. Otherwise you will eventually run out of memory.
Apr 20, 2009 12:54 PM|Paul W Johnston|LINK
You can always get the username of the current user once they have been authenticated by checking HttpContext.Current.User.Identity.Name.
If you are using a membership provider, then you can call Membership.GetUser(). This will return the currently logged in user. Use this to get the username and the user provider key (which is the "user id").
So you see it shouldn't be neccesary for you to store this information in the session at all.
Apr 20, 2009 01:24 PM|andieje|LINK
I was always told that you should avoid trips to the database whereever necessary so I guess this is why I store things like the username in a session cookie. I might re-think storing those details in session based on what you've just said but for now I
am interested in a solution to this problem regardless in case i come across it again which I'm sure I will so I would really appreciate it if you could humour me and assume for now we have to use session variables to store a couple of bits of user info.
My website is a gps tracking site. People have the option to use the remember me option and create a permanent FA cookie. I want the user to be remembered if they don't use the website overnight and for the weekend but if they are away for a week I want
them to have to login again. So i have set the FA timeout value to 7200 minutes (5 days)
In the session info I am simply storing the userID and their name. I want to make sure the session never times out before the FA. Both session and FA use a sliding expiration but the session expiration is updated on every page request but the FA is only
updated if more than half of the timeout amount has expired. If my logic is correct and I set the session and FA timeouts to be the same value in the web.config then the timeout value of the FA ticket could be less than the session timeout on the server but
never the session timeout value will never be less than the expiration value stored in the FA ticket. So if I set my session timeout to the same as the FA ticket session variables should never expire before the FA ticket. (They always seem to timeout though
don't they no matter what you set!!!)
If the user selects remember me, closes the browser and reopens it, they will still be logged in but their session will be lost so I need to repopulate the session. I will do this in the Session_Start event with the code
If the user doesn't select remember me and closes the browser and reopens it, they won't be logged in and their session state will be lost. The FA module will redirect the user to the login page. After login in the LoggedIn event I can populate the session.
I think that should cover me. I presume though it wouldn't do any harm to check for session timeouts. I have seen this done a couple of ways. MOst ways involve looking in the session start event to see if the sessionID cookie exists.
What do you think?
Apr 20, 2009 01:27 PM|andieje|LINK
What do you consider to be a large timeout value? A week? A month? 3 months?
Apr 20, 2009 01:41 PM|malcolms|LINK
Well for myself a large session timeout is one hour. I hardly ever change the default timeout because for the work that I do and the companies I deal with, this is adequate. The session is a sliding expiration, so if your timeout is 20 minutes, the page
can be left alone for 19 minutes but if a user clicks on a button, the session won't time out but continue.
I do allot of work with custom membership providers and windows authentication, which means I always know who the user is, so when a users session does time out, I simply go off and retrieve and populate the session without the user ever knowing.
I just had a thought, you could make a small ajax UpdatePanel on a page and use the timer control to automatically post back the page every 5 minutes to keep the session alive for your scenario. That could work.
Apr 20, 2009 02:10 PM|Paul W Johnston|LINK
andieje, You punish my feeble brain....
I think you are right - there is no way the session cookie will expire before the FA cookie.
Your plan to use the session_start event and repopulate the session from some sort of persistence medium seems okay.
There is a gotcha I can think of - it the application pool is recycled a new machine key will be generated unless you define a static machine key in the web config file. This will invalidate any Forms Authentication tickets generated by the previous application
pool. The machine key is used in the symmetric encryption algorithms for Forms Authentication. You will need to define a static machine key.
Good security practices would then have you encrypting the machine key section web config file of course.
Database access is the basis of just about useful web application in the universe !!! I really think you should look at user profiles - this is the problem they solve.
Apr 20, 2009 08:08 PM|andieje|LINK
I don't really know anything about application pool recycling. I will look this up. We own the server the application runs on so if you could give me some pointers on what I need to know about this. When our company gets bigger we will employ a proper person
to handle security and stuff but for now its all me and I'm a jack of all trades, master of none.
But back to the forms authentication issue, if the app pool is recycled and the fa tickets are lost then the user will have to login again and we will populate the session in the LoggedIn event. This is a similar scenario to the first time the user logs
on. Is this correct?
Apr 20, 2009 08:10 PM|andieje|LINK
Thanks Malcolm. I have a custom memberhsip provider for mysql. I adapted the one someone has provided on the web. Have you ever made one for mysql? thanks
Apr 20, 2009 10:44 PM|Paul W Johnston|LINK
If the app pool is recycled is and the FA ticket is lost then it is similar scenario to the first time a user logs in.
I wouldn't go increasing the lifetime of an applicaton pool just to stop FA tickets expiring - application pools are recycled for performance reasons.
It is far better to create a static machine key in the your application configuration file. There should plenty of exmaples of how to do this.
Apr 21, 2009 04:21 AM|malcolms|LINK
I have adapted one for mysql. The beauty of using a custom membership and role provider is that it can be used by anything, be it sql server, oracle or mysql.
Apr 22, 2009 12:12 AM|andieje|LINK
Thanks to Paul and Malcolm. Your comments and insights have been invaluable to me on this post.
Apr 23, 2009 10:46 AM|guybrush|LINK
You also might find the following two articles interesting:
They provide some insight into session management, session expiry, long session timeouts, application pool recycling and so on.
Apr 29, 2009 05:20 PM|andieje|LINK