In effect (declic video) we identified that Forms / Windows auth was in effect, and bumped up all the timeout settings ... including a "KeepAlive" aspx page performing a content refresh every 10 seconds embedded in the modules edit control (small iframe) .... bumped session timeouts to 2 hours, Forms Auth cookie timouts to 4 hours (ensure a 2 hr bus. req. window)... drastic sanity measures. This seems to work, but shouldn't really be necessary.
The issue seems to be completely controlled by the Authentication Cookie Timeout setting in IIS ... ASP.NET ... Configuration ... Authentication tab ... in our case. (after exhaustive testing).
Since we indeed are using Forms authentication within the web config ...to allow us to login with Windows authentication and forms auth (host/admin), it is readily apparent that the default value (global auth) of 30 minutes is insufficient.
From my reading, this 30 minute window is really a 15:01 window if you start a form (Edit control of a module) after signon at 14:59 seconds (asssuming Enable Sliding Expiration is checked). Had you started the form at 15:01, this setting would have updated your authentication "cookie" and given you another half hour. So basically this setting was giving us the resultant behavior of users trying to submit their form after 15-30 minutes of idle time, and the page basically refreshing (bypassing the postback, and subsequent form processing within the edit control).
Now we realize that simply increasing this setting seems to be the natural solution, let me preface that suggestion with "This is a security issue" for sites that want their users to expire after 15-30 minutes of idle time .. IE banking sites etc...
What is still unclear is the other IIS settings that control Session Timeout (State Management tab) and Application Pool settings for recycling worker processes, notes in MSDN for Health monitoring causing issues with worker processes, Web Garden Settings (WP >1), etc and how all of these settings work together.
A clear summary or hierarchy would be nice ... here's my guess. Correct me if I'm wrong here or missed something! 2003 Server is assumed.
Application Pools - Handle Worker Process (IIS Threads) If these recycle while a user is on your site, all bets are off. Samme as Restarting IIS
Website Properties ... Home Directory ... Application Settings ... Configuration .. Options
Enable Session State checkbox is checked default value is 20 minutes. This controls Session state I believe for ASP applications and can be unchecked for DNN / ASP.NET sites ... assuming you dont need session onstart / onend events???
WebSite Properties ... ASP.NET ... ver 2.x ... Global (machine.config) / Edit (web.config) Configuration ...
Authentication TAB.. Forms Authentication .. Cookie timeout (def 30 min) and Enable sliding expiration checkbox. Controls the length in minutes (sliding) before the users authentication runs out between page requests. The user will get re-authenticated, and DNN will login the user and redirect to the current Page (url) no postback occurs (forms auth).
State Management TAB ... InProc/UseCookies ... Session timeout (def 20). Controls ASP.NET session itself, NOT Forms Authentication cookies .. setting this higher does NOT override Forms Authentication cookie timouts. Would most likely affect Windows authentication on ASP.NET sites? We set this to 120 min (2hrs)
Any other thoughts? And please dont remind me how inefficent this all is on server resources, or the number of user sessions that will remain open because of this, etc ... :)
Also, was there a better (interface driven) way to activate the provided KeepAlive.aspx on the DNN root within(on) an edit controls page? Would have been nice to simply drop that control in and walk away without editing our module ... moving it from dev-qa-prod, etc. With the business owner breathing down our neck, asking if it was fixed yet. Whew!
Thanks!
Chuck