reasons for being logged out before actual timeout in Forms Authentication

Question

I have a asp.net MVC 3.0 website hosted on a subdomain of a main website . Asp.net version is set to .Net 4.0 integrated pipeLine .

the Forms Authentication settings is as below :

<authentication mode="Forms">
  <forms
          cookieless="UseCookies"
          defaultUrl="~/home"
          enableCrossAppRedirects="false"
          path="/"
          requireSSL="false"
          loginUrl="~/account/login"
          protection="All"
          timeout="120"
          slidingExpiration="true"
          name=".SubDomainAuthCookie"></forms>
</authentication>

but it logs me out just after few minutes each time ! the Host Admins say that is maybe because of improper coding or heavy tasks that cause the application pool to reset , but it's a simple mvc website with EF ORM . I can't figure out what to do ! what should I look for as possible cause of this situation ?

Update :

after checking Application_Start , I find that it's the problem , I logged Application_Start() and the result is whenever I'm being logged out , a log is added .

12/6/2012 12:14:03 PM ==> Application started
12/6/2012 12:16:35 PM ==> Application started
12/6/2012 12:22:59 PM ==> Application started

strange ,but real . there is nothing complicated or heavy in the logic ! Could EF be the problem , does it consume a lot of memory/CPU that cause application pool to reset ?

score 3 · Accepted Answer · edited Nov 11 '17 at 04:50

3

Check there's no other application using name=".SubDomainAuthCookie". These applications can overwrite their cookies.
Are you using FormsAuthentication.SetAuthCookie before calling FormsAuthentication.RedirectFromLoginPage in login page? If not, probably authentication cookies are not set properly.
Try to log Application_End of global.asax.cs to know if your app is recycling too much.

protected void Application_End(object sender, EventArgs e) { /log the Application_End/ }

As mentioned by @ZippyV in one of the answers below, the reason behind this is that IIS is by default set to automatically generate a pair of keys for decryption and validating authorization cookie contents (as well as other things) on each AppPool recycle called MachineKey. Also mentioned in this question

When this key is changed, stored authorization cookie contents on all browsers is no longer readable and authorization is lost.

The most simple remedy is to use a static MachineKey in your web.config
Also try to set the cookies to be the parent domain. more info here.

edited Nov 11 '17 at 04:50

mohas

1,911
1
16
20

answered Dec 06 '12 at 07:01

VahidN

18,457
8
73
117

thank you for suggestions , 1- no , it's unique , 2- yes , I am , 4- I try but no difference , currently trying number 3 – mohsen dorparasti Dec 06 '12 at 07:37
1

check out this post about application restarts: http://www.dotnettips.info/Post/516 – VahidN Dec 06 '12 at 10:00
2

+ unhandled exceptions can cause application restarts. add ELMAH to investigate it. – VahidN Dec 06 '12 at 11:12
I'm acting strange today ! I forgotted ELMAH totally , thank you – mohsen dorparasti Dec 06 '12 at 11:40
unfortunately no unhandled exception logged – mohsen dorparasti Dec 06 '12 at 17:37

score 1 · Answer 2 · answered Dec 06 '12 at 13:34

1

I had this problem too when my hosting provider recycled my site's process too often. For some reason the authentication cookie becomes invalid because the encryption/decryption keys change. And so your site is not able to read the authentication cookie anymore.

You can solve this problem by specifying the keys in your web.config so that they can't get changed by your hosting provider:

Go to http://aspnetresources.com/tools/machineKey and click the button
Copy the generated tag
Open your web.config file and paste the generated tag inside <system.web>

answered Dec 06 '12 at 13:34

ZippyV

12,540
3
37
52

are there any security risks using this approach ( specifying machine key manually in the web.config )? – mohsen dorparasti Dec 06 '12 at 17:10
Don't deploy multiple sites with the same machinekey and when security gets breached generate a new one. – ZippyV Dec 06 '12 at 20:53
The `machineKey` link is broken. – CSJ Dec 14 '14 at 22:13
@CSJ Let's hope it's temporary. – ZippyV Dec 14 '14 at 23:22
How to generate machine Key using IIS itself [Easiest way to generate MachineKey](https://blogs.msdn.microsoft.com/amb/2012/07/31/easiest-way-to-generate-machinekey/) – mohas Nov 10 '17 at 20:23

score 0 · Answer 3 · answered Dec 06 '12 at 09:13

You also want to set the expire time of cookie which has been generated while you log in. And in form authentiction you have to use this.

FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1, //Here Userinformation, DateTime.Now, DateTime.Now.AddDays(1), false, string.Empty);

Here i have set the expire of cookie to DateTime.Now.AddDays(1) (loggin date+1day) so its too long it will be logged in. So the created ticket will be expired on next day from when you logged in.

And in Web.Config

  <authentication mode="Forms">
  <forms loginUrl="~/Account/LogOn" timeout="2880" />
</authentication>

Now for a long time you can be logged in.

Hope it helps!!!

Check these links for deeper clarification on create loggin and expire time.

http://www.hanselman.com/blog/WeirdTimeoutsWithCustomASPNETFormsAuthentication.aspx

And

http://codeasp.net/blogs/vivek_iit/microsoft-net/848/forms-authentication-timeout-vs-session-state-timeout

score 0 · Answer 4 · answered Dec 06 '12 at 10:05

0

Have you checked value in SessionState? It's default value is 20 Mins. You need to update it to same or greater than form authentication ticket.

Please add/update following tag in your configuration file.

**<sessionState timeout="120" />**

answered Dec 06 '12 at 10:05

alok_dida

1,723
2
17
36

Session State is not the problem , the problem is that the application is recycling too much and fast . – mohsen dorparasti Dec 06 '12 at 10:29
Have you tried this solution? If you have not defined this tag then after default time your session will be expired. – alok_dida Dec 06 '12 at 11:11
Session has nothing to do with Authentication. – ZippyV Dec 06 '12 at 13:21
I know. It is very simple that. You have set FormAuthentication timeout to 120. If you do not defined Sessionstate than defaul session timeout is 20. Currently you have not defined sessionstate tag in web.config so that your ticket will be expired after 120 but your session will be expirted after 20. Your session is going to expire after 20 so that you will be redirect to login page. You are getting me what i am trying to say? – alok_dida Dec 07 '12 at 04:34

reasons for being logged out before actual timeout in Forms Authentication

4 Answers4