Re: [Cosign-discuss] how hard would it be to fix the post_error problem?
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
Re: [Cosign-discuss] how hard would it be to fix the post_error problem?
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. -- Mark Montague m...@catseye.org -- 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
Re: [Cosign-discuss] how hard would it be to fix the post_error problem?
On 2014-07-09, 16:23, Chris Hecker wrote: 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. That could work. But keep in mind that the user would upload the data to the central weblogin server when they were redirected there, then the data would be downloaded in the login page, uploaded again when the user submitted the login page -- and this would download/upload/download cycle would repeat each time the user had an authentication error such as a mistyped password -- and then downloaded again to the user's browser when the user was redirected back to the cosign-protected web server, and then finally uploaded to the cosign-protected web server (assuming that the web server didn't bounce them back again to satisfy an additional factor or for some other reason). Now image that the message the user was adding to the forum thread that triggered the reauthentication event included a 100 MB video attachment and that the user was on a slow broadband connection at home. I do think that this problem might be solvable, I just wanted to point out that the solution should be carefully designed -- I think there are a number of interesting edge cases and issues that would have to be considered. In the meantime, individual institutions that use cosign could modify their post_error.html to include a link to Lazarus and similar browser plugins so that the user could install one and avoid the loss next time. -- Mark Montague m...@catseye.org -- 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
Re: [Cosign-discuss] how hard would it be to fix the post_error problem?
I've wondering if the additions to httpd 2.4 that support mod_auth_form could be leveraged by mod_cosign. http://httpd.apache.org/docs/2.4/mod/mod_auth_form.html One specific part of that is Inline Login with Body Preservation http://httpd.apache.org/docs/2.4/mod/mod_auth_form.html#inlinepreservebody which mentions preserving POST data. -Phil Pishioneri -- 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
Re: [Cosign-discuss] how hard would it be to fix the post_error problem?
I wonder if I could do a cheesy workaround for my site that would use javascript to hook the post button on the forum page, and then test for expired credentials, and then pop up a login box if they are, then resume the post. It's a hack, but it might work. 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
Re: [Cosign-discuss] how hard would it be to fix the post_error problem?
On 2014-07-09, 16:24, Chris Hecker wrote: I wonder if I could do a cheesy workaround for my site that would use javascript to hook the post button on the forum page, and then test for expired credentials, and then pop up a login box if they are, then resume the post. It's a hack, but it might work. We have a certain web application here at U-M that uses Javascript to check back with the web server every 60 seconds to see if there is new content that should be displayed for the user. This has the interesting side effect of disabling the cosign idle (or soft) timeout (2 hours) and detecting the cosign hard timeout (10, 12, or 24 hours) when as soon as it occurs. It's not nearly as good as your proposed workaround, but I've noticed that people of that particular webapp rarely wind up losing POST data. -- Mark Montague m...@catseye.org -- 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
