Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: Stopping Multi-submits ? Date: Wed, 24 Sep 2014 02:50:48 +0200 Organization: PointedEars Software (PES) Lines: 53 Message-ID: <3821481.YS7cT2vfY4@PointedEars.de> References: Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: solani.org 1411519850 19167 eJwNyMEBwCAIA8CVBExwHdCw/wjtPQ9B481NcGMwbqBXhwVeSupQV7InmDqN/5Y5UHcd1ZsPIR8RuA== (24 Sep 2014 00:50:50 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Wed, 24 Sep 2014 00:50:50 +0000 (UTC) User-Agent: KNode/4.14 X-User-ID: eJwNx8EBwCAIA8CVQAzCOBhk/xHa+x3M1Xm2wzcGM13Sfy0mMutlXgVUlhzLZb37EcnQJ7NYFnGpjOIoL+EfTbYVyw== Cancel-Lock: sha1:aqmRI5E67Ez9m+CFb9d9pAJ+M7o= X-NNTP-Posting-Host: eJwFwQkRADAIAzBLwCiPnK0H/iUswQkNpgfCsVgLvdS1ft1pKS071VZwGNVwxIWXxRnsS34C8RCm Xref: csiph.com comp.lang.javascript:25865 Cezary Tomczyk wrote: > On 2014-09-23 16:58, Mel Smith wrote: > [...] >> Problem: >> >> In IE11 (at least), after the new page arrives, if the user decides >> to use the 'back arrow' to re-load the previous page, then that >> submit button is *still* disabled, when I wish it to be enabled and >> ready for another submit >> >> Question: >> >> How do I restrain multiple submits, *but* allow submits again after >> a new page has arrived, and then the user 'arrows' back to the >> previous page (or pages). > [...] > > Maybe do not disable the button, but instead of that when user clicks on > the button set some state, e.g.: > > var submitState = false; > > to "true" and when the user clicks on button again just check that state > and do the right action, e.g. if the state == true then show the message > for the user that his "request is still in progress". However, there is no guarantee that, using the Back feature, the pre- existing environment will not be sufficiently restored. A sufficiently reliable client-side possibility are cookies or Local/Session Storage instead; IOW, anything that is *not* tied to the document or view. HTML5 Push State and equivalents come to mind as well even though they are tied to the view. Eventually, this can only be solved reliably server-side, by generating forms that are not cached (although this could be ignored by the UA as well), and submit tokens that are generated once, stored in a server-side session, and expire on successful form submission (anything else could result in accidental submission if the Forward feature is used subsequently). This is also the recommended usability and security measure, given that client-side script code need not be executed. It is possible to use XHR to improve the user experience, though: the submission of forms whose token has expired can be cancelled in advance. The negligible extra cost of this measure can result in a significant reduction of server load, depending on how much data is being sent when the submission is successful. -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not Cc: me. / Bitte keine Kopien per E-Mail.