RE: Question on Double Submit and rendering strategy

[Bernard Bernard]

Hi Mark,

I read your post on the Wicket users list.

Prevention of double submits can safely be achieved with an old J2EE design
pattern, a server token.

So the server generates a token for the form and expects it on submission.
After the first submission it is invalidated and subsequent submissions
will get a different response.

In Wicket, this is very easy to solve 1) if one includes the server token
in a form field (interestingly, the page already has a token to prevent
CSRF attacks), and 2) if one ensures that there is only a single instance
of the page for an existing session.

This is a stateful solution obviously but here, server state really pays
dividends.

There might be issues with forcing a single page instance per session, but
it is possible that any other mechanism implementing the server side token
pattern suffer from similar issues.

Please see https://issues.apache.org/jira/browse/WICKET-5810 for the
experimental concept of a singleton page which you could use to implement
your server token solution. The singleton concept would even cover the case
where the user has the same form open in two windows and does the bad
thing. I would not want to depend on JavaScript for double submit
prevention. I have seen in production duplicate orders with JavaScript
prevention.

Regards,

Bernard

RE: Question on Double Submit and rendering strategy

[Hesketh, Mark]

Thanks for that Martin - I understand. Thanks also for the alternate approaches.

I think we might experiment with the AjaxChannel#ACTIVE approach as an 
alternative although we do have the veil approach ready to ship.

Cheers.

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Monday, 24 November 2014 7:08 PM
To: users@wicket.apache.org
Subject: Re: Question on Double Submit and rendering strategy

Hi,

What you observe is correct !

Wicket support for Redirect after Post
<http://en.wikipedia.org/wiki/Post/Redirect/Get> is to prevent double submit of 
a form if the user reloads the page (Ctrl+R or F5) or if the user navigates 
back. In these cases usually the browser would ask you whether you want to 
re-send the form data. With the REDIRECT_TO_XYZ strategies this is avoided.

As you have found out this doesn't cover the cases when the user clicks several 
times on a submit button/link. The only support for this in Wicket is to use 
AjaxChannel#ACTIVE for Ajax submit buttons/links. Using an active channel will 
prevent any following Ajax call while there is an active one with the same 
channel name. But this solution doesn't provide visual feedback for the user. 
It just silently ignores the click event.

Other ways to prevent multiple submits are not so generic and that's why they 
are not provided by Wicket itself.
These include:
- Disable the button/link somehow
Wicket 6.x replaces  with  by default but this is not acceptable 
by some applications.
Wicket-Bootstrap <https://github.com/l0rdn1kk0n/wicket-bootstrap> for example 
follows Bootstrap recommendations for making the button/link look and act as 
disabled
- Show a veil
Some apps prefer to veil only the button. Others the whole screen. Others some 
area, e.g. just the form.
The UI used as a veil also differs for most applications... That's why Wicket 
doesn't provide a generic solution here.

Any feedback about this and other topics in Wicket are very welcome !

On Mon, Nov 24, 2014 at 1:36 AM, Hesketh, Mark 
wrote:

> Hi
>
> Please give more details what you try to avoid exactly by making
> changes in this area.
> [MH] Hello again,
> [MH] Well, I'm trying to avoid Double Submit through repeatedly button
> clicking (or submitting a form). We're currently [MH] porting all our
> web applications to Wicket. We have had to include a veil function
> around the Next button [MH] to block subsequent clicks explicitly as
> Wicket's Double Submit prevention (we are using the default
> RENDER_TO_BUFFER render strategy) [MH] is allowing repeated requests
> through. I've stepped through
> WebPageRenderer::respond() and noticed that there's a call [MH] to
> getAndRemoveBufferedResponse() and stopped looking since I could see
> that responses were being discarded. I just assumed that I am
> misunderstanding [MH] the full intent of the Double Submit treatment
> in Wicket. Hope that makes sense. I'm not wanting to *change* Wicket
> here, I'm chasing clarification only given what [MH] what I've stepped
> through and hear that from the maintainers directly. I guess I'm
> confused about what happens when there's more than one duplicate
> request when [MH] clearly the implementation is discarding (by design)
> the buffered response to an identical earlier request.
> [MH]
> [MH] Many thanks
>
> > Hello,
> >
> > I just wanted to know what the impact of removing the buffered
> > response (referring to javadoc below for REDIRECT_TO_BUFFER) for a
> > request is if there's presumably a bunch of other duplicate requests
> > following it on solving the Double Submit problem.
> > (
> > http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/s
> > et
> > tings/IRequestCycleSettings.html
> > )
> >
> > I'm puzzled about throwing a response away when I would have thought
> > it's buffered and reused to service the (duplicate) requests following?
> >
> > Many thanks
> >
> > cheers.
> > -m.
> >
> >
> > 
> > --
> > - This email, and any attachments, may be confidential and also
> > privileged.
> > If you are not the intended recipient, please notify the sender and
> > delete all copies of this transmission along with any attachments
> > immediately. You should not copy or use it for any purpose, nor
> > disclose its contents to any other person.
> > 
> > --
> > -
> >
> 

Re: Question on Double Submit and rendering strategy

[Martin Grigorov]

Hi,

What you observe is correct !

Wicket support for Redirect after Post
 is to prevent double
submit of a form if the user reloads the page (Ctrl+R or F5) or if the user
navigates back. In these cases usually the browser would ask you whether
you want to re-send the form data. With the REDIRECT_TO_XYZ strategies this
is avoided.

As you have found out this doesn't cover the cases when the user clicks
several times on a submit button/link. The only support for this in Wicket
is to use AjaxChannel#ACTIVE for Ajax submit buttons/links. Using an active
channel will prevent any following Ajax call while there is an active one
with the same channel name. But this solution doesn't provide visual
feedback for the user. It just silently ignores the click event.

Other ways to prevent multiple submits are not so generic and that's why
they are not provided by Wicket itself.
These include:
- Disable the button/link somehow
Wicket 6.x replaces  with  by default but this is not
acceptable by some applications.
Wicket-Bootstrap  for
example follows Bootstrap recommendations for making the button/link look
and act as disabled
- Show a veil
Some apps prefer to veil only the button. Others the whole screen. Others
some area, e.g. just the form.
The UI used as a veil also differs for most applications... That's why
Wicket doesn't provide a generic solution here.

Any feedback about this and other topics in Wicket are very welcome !

On Mon, Nov 24, 2014 at 1:36 AM, Hesketh, Mark 
wrote:

> Hi
>
> Please give more details what you try to avoid exactly by making changes
> in this area.
> [MH] Hello again,
> [MH] Well, I'm trying to avoid Double Submit through repeatedly button
> clicking (or submitting a form). We're currently
> [MH] porting all our web applications to Wicket. We have had to include a
> veil function around the Next button
> [MH] to block subsequent clicks explicitly as Wicket's Double Submit
> prevention (we are using the default RENDER_TO_BUFFER render strategy)
> [MH] is allowing repeated requests through. I've stepped through
> WebPageRenderer::respond() and noticed that there's a call
> [MH] to getAndRemoveBufferedResponse() and stopped looking since I could
> see that responses were being discarded. I just assumed that I am
> misunderstanding
> [MH] the full intent of the Double Submit treatment in Wicket. Hope that
> makes sense. I'm not wanting to *change* Wicket here, I'm chasing
> clarification only given what
> [MH] what I've stepped through and hear that from the maintainers
> directly. I guess I'm confused about what happens when there's more than
> one duplicate request when
> [MH] clearly the implementation is discarding (by design) the buffered
> response to an identical earlier request.
> [MH]
> [MH] Many thanks
>
> > Hello,
> >
> > I just wanted to know what the impact of removing the buffered
> > response (referring to javadoc below for REDIRECT_TO_BUFFER) for a
> > request is if there's presumably a bunch of other duplicate requests
> > following it on solving the Double Submit problem.
> > (
> > http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/set
> > tings/IRequestCycleSettings.html
> > )
> >
> > I'm puzzled about throwing a response away when I would have thought
> > it's buffered and reused to service the (duplicate) requests following?
> >
> > Many thanks
> >
> > cheers.
> > -m.
> >
> >
> > --
> > - This email, and any attachments, may be confidential and also
> > privileged.
> > If you are not the intended recipient, please notify the sender and
> > delete all copies of this transmission along with any attachments
> > immediately. You should not copy or use it for any purpose, nor
> > disclose its contents to any other person.
> > --
> > -
> >
> ---
> This email, and any attachments, may be confidential and also privileged.
> If you are not the intended recipient, please notify the sender and delete
> all copies of this transmission along with any attachments immediately. You
> should not copy or use it for any purpose, nor disclose its contents to any
> other person.
> ---
>

RE: Question on Double Submit and rendering strategy

[Hesketh, Mark]

Hi

Please give more details what you try to avoid exactly by making changes in 
this area.
[MH] Hello again,
[MH] Well, I'm trying to avoid Double Submit through repeatedly button clicking 
(or submitting a form). We're currently
[MH] porting all our web applications to Wicket. We have had to include a veil 
function around the Next button
[MH] to block subsequent clicks explicitly as Wicket's Double Submit prevention 
(we are using the default RENDER_TO_BUFFER render strategy)
[MH] is allowing repeated requests through. I've stepped through 
WebPageRenderer::respond() and noticed that there's a call
[MH] to getAndRemoveBufferedResponse() and stopped looking since I could see 
that responses were being discarded. I just assumed that I am misunderstanding
[MH] the full intent of the Double Submit treatment in Wicket. Hope that makes 
sense. I'm not wanting to *change* Wicket here, I'm chasing clarification only 
given what
[MH] what I've stepped through and hear that from the maintainers directly. I 
guess I'm confused about what happens when there's more than one duplicate 
request when
[MH] clearly the implementation is discarding (by design) the buffered response 
to an identical earlier request.
[MH]
[MH] Many thanks

> Hello,
>
> I just wanted to know what the impact of removing the buffered
> response (referring to javadoc below for REDIRECT_TO_BUFFER) for a
> request is if there's presumably a bunch of other duplicate requests
> following it on solving the Double Submit problem.
> (
> http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/set
> tings/IRequestCycleSettings.html
> )
>
> I'm puzzled about throwing a response away when I would have thought
> it's buffered and reused to service the (duplicate) requests following?
>
> Many thanks
>
> cheers.
> -m.
>
>
> --
> - This email, and any attachments, may be confidential and also
> privileged.
> If you are not the intended recipient, please notify the sender and
> delete all copies of this transmission along with any attachments
> immediately. You should not copy or use it for any purpose, nor
> disclose its contents to any other person.
> --
> -
>
---
This email, and any attachments, may be confidential and also privileged. If 
you are not the intended recipient, please notify the sender and delete all 
copies of this transmission along with any attachments immediately. You should 
not copy or use it for any purpose, nor disclose its contents to any other 
person.
---

Re: Question on Double Submit and rendering strategy

[Martin Grigorov]

Hi

Please give more details what you try to avoid exactly by making changes in
this area.
On Nov 21, 2014 12:25 AM, "Hesketh, Mark"  wrote:

> Hello,
>
> I just wanted to know what the impact of removing the buffered response
> (referring to javadoc below for REDIRECT_TO_BUFFER) for a request is if
> there's presumably a bunch of other duplicate requests following it on
> solving the Double Submit problem.
> (
> http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/settings/IRequestCycleSettings.html
> )
>
> I'm puzzled about throwing a response away when I would have thought it's
> buffered and reused to service the (duplicate) requests following?
>
> Many thanks
>
> cheers.
> -m.
>
>
> ---
> This email, and any attachments, may be confidential and also privileged.
> If you are not the intended recipient, please notify the sender and delete
> all copies of this transmission along with any attachments immediately. You
> should not copy or use it for any purpose, nor disclose its contents to any
> other person.
> ---
>