I would think the current post could be stuffed into the post_error.html page (or its replacement) when it's generated, then carried across to the login page, and then reposted, so it wouldn't require javascript at all. I haven't thought about it too much, though.
It's just a terrible user experience, so it'd be nice to fix it. Chris On 2014-07-09 13:10, Mark Montague wrote: > On 2014-07-09, 15:11, Chris Hecker wrote: >> I just got burned by this on my own site, losing a forum post that took >> me a while to write. How hard would it be to fix this issue, it really >> sucks to lose the user's (read: my) data. > > The easy solution is to use a browser add-on such as Lazarus that will > recover the data for you when this happens: > http://getlazarus.com/download I use this in Firefox and it works well. > > Note that this is not an issue with cosign per se, but rather an issue > with how HTTP redirects work: The web browser will hold on to the body > data for the original POST request across multiple redirects, but > discards it as soon as the ultimate request either succeeds (2xx status) > or fails (4xx or 5xx status). The problem is that the user winds up at > the central weblogin server to reauthenticate, which serves the login > page to the user (200 status) -- at this point, the browser discards the > unread POST body data from the original HTTP request. > > When I was still working for the central IT organization at the > University of Michigan, I did some thought experiements on what it might > take to add a feature to cosign that would preserve POST data across > reauthentication events. At the time, I thought it *might* be possible, > although tricky. The POST data would have to be grabbed by something at > the start of the reauthentication event (perhaps by mod_cosign before it > redirected the user to the central weblogin server?) and saved. At the > end of the reauthentication, the original POST request would have to be > regenerated -- in theory, mod_cosign could dynamically generate a page > for the user that contained JavaScript that would re-issue the POST > request. > > Some concerns include: > 1. If JavaScript is needed, the solution would not work with all > browsers; ideally, things would be designed to degrade gracefully. > 2. How much POST data should be accepted by cosign and saved? There are > potential denial-of-service concerns here, not to mention the time > required to upload, then download, then upload a large amount of POST > data especially if the user is on an asymmetrical connection such as DSL > or cable modem. > 3. Related to (2) how many POST variables should be supported? > 4. How long should POST data be held? 5 minutes? longer? shorter? > There are potential security concerns here, too, not to mention web > application timeout concerns for webapps that expect the form to be > submitted within a certain window. > 5. There are undoubtedly other concerns too. > > This might be a fun experimental project for someone with free time. > > ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
