<p>Bill,</p>
<p>I am preparing to write an app with a very long form, and I am concerned about the same problem. My current plan is to use ajax to send an update for each field entered (and store it in db). This does increase load on the server, but as long as each field is not long, it keeps amount of work that can be lost reasonably small. </p>
<p>But if you have large text fields where user is supposed to enter several pareagraphs then maybe something like gmail which autosaves message text after some time passes might be the way.</p>
<p>Lastly maybe you could deal with expiry problem by acting before it happens. Something like innactivity timer in browser which jumps to special "inactivity page", which displays password reentry dialog, and until user enters pass it sends in backgropund ajax session keep alive packets. When user submits the password, you transfer control back to the calling page. If he closes window, session eventually expires.</p>
<p>rush<br>
<a href="http://www.cloud208.com/">http://www.cloud208.com/</a><br>
</p>
<p><blockquote type="cite">On Sep 25, 2009 4:19 PM, "Schwab,Wilhelm K" <<a href="mailto:bschwab@anest.ufl.edu">bschwab@anest.ufl.edu</a>> wrote:<br><br>Hello all,<br>
<br>
I am gradually gaining confidence with mixing Seaside and SSL. The next step is to ensure that only authenticated users can access the application(s), which seems easy enough by simply demanding a password in the first component. I have some more work to do, such as allowing users to change their password (unless I pawn that off to our directory system), and ideally finding a nice way to persist (hashed of course) passwords either in a database or other storage. If any of you have particularly elegant solutions to the latter, I'd be all ears :)<br>
<br>
My current concern is over work a user might do in a session that expires. I would rather not have to answer with: "sorry, it's gone, you're screwed, work faster next time," but that would be far better than security breaches, and the application already allows the user to attack the work a few small bites at a time. Is there a robust way to drop the user into a task/loop that re-authenticates and then allows work to continue where the user lefr off? If they close the browser, I have no sympathy; I'm thinking of timeouts.<br>
<br>
Bill<br>
<br>
_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
</blockquote></p>