views:

1240

answers:

5

I have a form that sits behind ASP.NET forms authentication. So far, the implementation follows a typical "out of the box" type configuration.

One page allows users to post messages. If the user sits on that page for a long time to compose the message, it may run past the auth session expiration. In that case, the post does not get recorded... they are just redirected to the login page.

What approach should I take to prevent the frustrating event of a long message being lost?

Obviously I could just make the auth session really long, but there are other factors in the system which discourage that approach. Is there a way I could make an exception for this particular page so that it will never redirect to the Login so long as its a postback?

A: 

Don't include it in the authentication zone for your website. Users will not be redirected if there is no session when authentication is not required. You could place a login control on the confirmation page, if you require the user to be logged in in order to record the submission, and record the form data upon successful authentication.

Kyle Trauberman
A: 

My coworker came up with a general solution to this kind of problem using an HttpModule.

Keep in mind he decided to to handle his own authentication in this particular application.

Here goes:

He created an HttpModule that detected when a user was no longer logged in. If the user was no longer logged in he took the ViewState of that page along with all the form variables and stored it into a collection. After that the user gets redirected to the login page with the form variables of the previous page and the ViewState information encoded in a hidden field.

After the user successfully reauthenticates, there is a check for the hidden field. If that hidden field is available, a HTML form is populated with the old post's form variables and viewstate. Javascript was then used auto submit this form to the server.

Min
+1  A: 

See this related question, where the answers are all pretty much themes on the same concept of keeping values around after login:

  • Login page POSTS username, password, and previous POST variables to referring page. Referring page logs in user and performs action.
  • Login page writes out the form variables and Javascript submits to the referring page after successful login
  • AJAX login

If you don't care if they're logged in or not when they POST (seems a little iffy security-wise to me...) then hooking HttpContext.PostAuthenticateRequest in an IHttpModule would give you a chance to relogin using FormsAuthentication.SetAuthCookie. The FormsAuthenticationModule.Authenticate event could be used similarly by setting an HttpContext.User:

// Global.asax
void FormsAuthentication_OnAuthenticate(object sender, FormsAuthenticationEventArgs e) {
   // check for postback somehow
   if (Request.Url == "MyPage.aspx" && Request.Form["MySuperSecret"] == "123") {
      e.User = new GenericPrincipal(new GenericIdentity(), new string[] { });
   }
}
Mark Brackett
A: 

When the session timeout happens the user's session (and page information) get disposed, which would mean the eventual postback would fail. As the others have suggested there are some work arounds, but they all assume you don't care about authentication and security on that particular page.

I would recommend using Ajax to post back silently every 10 mins or so to keep it alive, or increase the timeout of the session as you suggest. You could try to make a page specific section in your web config and include in there a longer timeout.

Robert Wagner
A: 

I handled this once by adding the form value to the database, identified by the remote IP instead of user ID.

( HttpContext.Request.UserHostAddress )

Then, after login, you can check to see if the current user's IP address has a row in the database, and perform the required action.

Michael

kaneuniversal