locked
Inactivity timeout RRS feed

  • Question

  • All, 

    I still didn't find a solution for the inactivity timout.

    After 5 minutes of inactivity, the authentication coockie is timed out. This results in the same problem for the lightswitch and the html client.

    I found a work around for the Silverlight client in creating a "hearbeat" timer that every 30 seconds does a simple query to the backend.

    I guess I can do something similar in the html client creating a time in the create event of the home page that does a similar simple query to the backend.

    this does not solve however the issue when I click the "remember me next time" in the logon page. Closing the browser and restarting again within 5 minutes works fine. I get automatically logged in, but waiting for more than 5 minutes before opening a new browser and navigating to the app doesn't automatically in. I guess the persistens authentication coockie is not valid anymore on the server.

    I thought the timout setting on the Forms authentication in the webconfig should to the trick, but I guess lightswitch has his own FormsAuthentication provider that does not take this parameter into account.

    Could someone help me out with this one?

    Cioao,

    Bert

    Wednesday, November 26, 2014 9:20 PM

Answers

  • Think so too that it's a provider issue.

    paul van bladel ==independent enterprise application architect== http://blog.pragmaswitch.com

    Thursday, November 27, 2014 4:15 PM
  • It is possible to make the authentication cookie "survive" the application pool recycling. Default encryption keys are auto generated, so when the application pool recycles, new ones are generated and the existing cookie coming from the browser cannot be decrypted anymore to get the ticket. IHowever, if you use the MachineKey in the web.config to put own generated keys. After application pool recycling, the authentication cookie still can be decrypted and the user is re-authenticated...
    Friday, November 28, 2014 5:54 PM

All replies

  • LightSwitch is using the forms auth provider as defined in web.config. No magic here.

    In my experience changing over there the timeout is working as advertised.


    paul van bladel ==independent enterprise application architect== http://blog.pragmaswitch.com

    • Proposed as answer by Paul Van Bladel Thursday, November 27, 2014 4:15 PM
    Wednesday, November 26, 2014 10:04 PM
  • It's strange you hit a timeout after 5 minutes. Since you didn't specify anything, the default value, which is 30 minutes should be applied.

    paul van bladel ==independent enterprise application architect== http://blog.pragmaswitch.com

    Wednesday, November 26, 2014 10:08 PM
  • I tried deploying on a local server and indeed the same issue arrives only after half an hour.

    I think it's still ugly that you get a browser popup for authentication which doesn't work. it should at least redirect to the login page...

    My application is hosted at hostforlife. Could it be they have some asp.net setting that overrules???

    any idea's?

    Thursday, November 27, 2014 12:06 PM
  • Paul,

    I think I have found the issue...

    I noticed that when I have a silverlight client open (that implemented the heartbeat solution), also the webclient didn't time out.

    I need to verify with the hosting provider, but i suspect they recycle the application pool after 5 minutes of inactivity timeout.

    Thursday, November 27, 2014 2:31 PM
  • Think so too that it's a provider issue.

    paul van bladel ==independent enterprise application architect== http://blog.pragmaswitch.com

    Thursday, November 27, 2014 4:15 PM
  • It is possible to make the authentication cookie "survive" the application pool recycling. Default encryption keys are auto generated, so when the application pool recycles, new ones are generated and the existing cookie coming from the browser cannot be decrypted anymore to get the ticket. IHowever, if you use the MachineKey in the web.config to put own generated keys. After application pool recycling, the authentication cookie still can be decrypted and the user is re-authenticated...
    Friday, November 28, 2014 5:54 PM