Last post Apr 28, 2014 01:43 AM by Katrad
Apr 24, 2014 01:42 PM|Katrad|LINK
My site is hosted with godaddy.com so it's in a shared hosting environment and there is no possiblity of changing the iis app pool settings. Also, the problem I'm having is doing this in both my development machine and the hosted server.
After moving to VS 2013, I have noticed that the website times out in about 2 minutes. I have set the session settings and forms authentication settings even created the authentication cookie and set the expiration there and still no change. My last bout with
this, I explicitly asked from code behind what the session timeout is and it states 20 minutes, even though it timeouts at 2 minutes.
When this started doing this on my development machine I thought I might find it more easily, but, I have no clue. I've read many, many posts on session, authentication, etc. tried many things, but, can't get above the 2 minutes.
Any help would be appreciated. Thanks in advance!
Apr 24, 2014 05:20 PM|hans_v|LINK
Apr 26, 2014 04:16 AM|Katrad|LINK
Sorry it took awhile to get back to you (and to others who wonder if this solution works). Well, doing the change seems to have cleared things up. Thank you very much, this has been an off and on pain in the neck for a month and a half and a lot of time
spent trouble shooting. Thanks so much.
Apr 26, 2014 04:27 AM|hans_v|LINK
The problem is that the Application Pool Recycles frequently in a Shared hosting Envrironment. When you didn't add a machinekey, ASP.NET generates a machinekey for you. This machinekey is used to encrypt/decrypt the authentication cookie (and also the viewstate).
But when the aoplication pool recycles, a new key is generated. But with this new key, the authentication cookie cannot be decrypted anymore so it can't be read, even if it is still valid, so the user is redirected to the login page. Using a machinekey wil
ensure that the same key is used on each and every request and the cookie can always be read.
So your forms authentication problem solved, but that has nothing to do with Session. By default, the Session State Mode is InProc, meaning it is stored in Memory. But when the application pool recycles, ALL session are lost. To prevent this, you need to
use another Session State Mode
Apr 28, 2014 01:43 AM|Katrad|LINK
Thank you for giving me more details, I've been looking for more reasons "why this worked" and your explanation was very helpful. Thank you again.