Does anyone else feel that this would be generically useful to have as a part
of Wicket? Not only does it prevent double submits, but it also is a simple
safeguard against cross-site request forgery (see
http://en.wikipedia.org/wiki/Cross-site_request_forgery for a summary).
The one missing
The one missing piece from your solution is synchronization. There is the
slightest possibility that the second submit of a double submit could enter
onSubmit before the token is reset. I am not yet sure what would be the best
object to synchronize on, possibly the session id?
Actually
do you have a good patch then?
And are you saying that all double submits are then not possible anymore?
Also when i submit then think hmm thats wrong back button change something
and submit again?
On Tue, Mar 25, 2008 at 3:25 PM, laz [EMAIL PROTECTED] wrote:
Does anyone else feel that
Sorry, I should have attributed that code to Joel.
-Original Message-
From: Zappaterrini, Larry [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2008 10:56 AM
To: users@wicket.apache.org
Subject: RE: Double submit problem
I don't have a patch, at this point I was just testing
Would something like this work?
public class SynchTokenField extends HiddenField
{
private String token;
public SynchTokenField(String id)
{
super(id, new PropertyModel(new ValueMap(), token));
setRequired(true);
add(new AbstractValidator()
{
shouldn't the token be cleared then somehow on the first request? (in the
validator)
now if the second time it still validates fine because the value that is
submitted doesnt change and the token in the field doesn't change.
But it is a nice simple idea to have
On Tue, Mar 25, 2008 at 5:40 PM,
So, it would be like this?
public class SynchTokenField extends HiddenField
{
private String token;
public SynchTokenField(String id)
{
super(id, new PropertyModel(new ValueMap(), token));
setType(String.class);
setRequired(true);
regenerateToken();
you should regen the token in onbeforerender()...
-igor
On Tue, Mar 25, 2008 at 10:09 AM, James Carman
[EMAIL PROTECTED] wrote:
So, it would be like this?
public class SynchTokenField extends HiddenField
{
private String token;
public SynchTokenField(String id)
{
Okay, how about this?
public class SynchTokenField extends HiddenField
{
private String token;
public SynchTokenField(String id)
{
super(id, new PropertyModel(new ValueMap(), token));
setType(String.class);
setRequired(true);
regenerateToken();
thats fine i gues, but a bit uglier with that null check
I guess your last one before this one would also suffice
because on every render the token doesn't need to change, why should it?
if i press refresh in the browser does the token has to be changed?
It isnt used anywhere at that time anyway.
Should this (or a prettied up version of it) go on the wiki or would
this be something that you guys would consider for the core (i.e.
submit a feature request)?
On Tue, Mar 25, 2008 at 1:27 PM, Johan Compagner [EMAIL PROTECTED] wrote:
thats fine i gues, but a bit uglier with that null check
if it was me something like this could go into extentions.
Or if people really want this as a visible security feature we could drop it
besides Form
johan
On Tue, Mar 25, 2008 at 6:30 PM, James Carman [EMAIL PROTECTED]
wrote:
Should this (or a prettied up version of it) go on the wiki or
On Tue, Mar 25, 2008 at 1:34 PM, Johan Compagner [EMAIL PROTECTED] wrote:
if it was me something like this could go into extentions.
Or if people really want this as a visible security feature we could drop it
besides Form
Is this the way you would suggest doing it? I was thinking a
I dont think this can be easily done by Behaviors or Validators
Only when we make it that a validator can also be a behavior (or provide a
behavior) then that would be possible.
for now Validatiors cant contribute to the html this is on the todo.
johan
On Tue, Mar 25, 2008 at 6:36 PM, James
On Tue, Mar 25, 2008 at 1:50 PM, Johan Compagner [EMAIL PROTECTED] wrote:
I dont think this can be easily done by Behaviors or Validators
Only when we make it that a validator can also be a behavior (or provide a
behavior) then that would be possible.
for now Validatiors cant contribute to
s/propertymodel.../new Model()/
s/if (token == null ||
!token.equals(validatable.getValue()))/!token.equals(validatable.getvalue())/
s/error(validatable)/error(FormTokenValidator)/ - no one wants to
define a SyncTokenField$AbstractValidator0 resource key
-igor
On Tue, Mar 25, 2008 at 10:19 AM,
something like this works fine if all you want to do is error out.
keeping in mind that wicket will synchronize requests already you can
actually provide a much better user experience if you sublcass this in
the form:
add(new secureform(form) {
onOriginaltSubmit() {
user
Does this stuff here prevent double submit?
http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/settings/IRequestCycleSettings.html
...so that not only form submits are shielded from the double submit
problem...
On Mon, Mar 10, 2008 at 6:56 AM, Joel Hill [EMAIL
that prevents that do you want to post the form again? dialog that
happens when you use the back button to go back to a page that had a
form you submitted.
-igor
On Mon, Mar 17, 2008 at 9:00 PM, Matthew Young [EMAIL PROTECTED] wrote:
Does this stuff here prevent double submit?
Here's a solution that SEEMS to be working. It incorporates our solution to
the double submit problem that we used on our JSP's. It didn't appear to be
working for me at first, but seems to be now. (It does use the old servlet
request/session objects, but this may change once all our old code
That would require me to either implement markup inheritance or to place the
hidden field in the markup of all my extended forms, wouldn't it? I was
hoping to make all my form instances as ignorant of the base class as
possible, but I guess if I have to implement one of these solutions, it's
Inside your onSubmit method do this
if(!submitted)
{
//normal submit code
submitted = true;
}
and have boolean submitted = false; in your class
that way no matter how many times someone clicks submit the submit code
should only run once
Thats one way anyway
hillj2 wrote:
That would
You could do it with javascript. Disable the button and change the button
label.
function saveForm(btn) {
eForm = document.forms[0];
btn.disabled=true;
btn.value='Please wait...';
eForm.submit();
return;
}
input type=button
In my original message, I said I wanted to avoid a javascript solution. It
doesn't lend itself to reuability, e.g. if I have multiple submit buttons or
specialized submit buttons. A more cumbersome solution, in my opinion.
rmattler wrote:
You could do it with javascript. Disable the
This was pretty much the original solution I linked. The problem comes when
you don't call setResponsePage() and go right back to the page (e.g. if some
custom form validation fails). It can no longer be submitted, because the
boolean is stuck in a true state.
--
View this message in context:
Not 100% sure, but you could implement a NoDoubleSubmitForm with a
couple of tweaks:
form ...
input type=hidden wicket:id=submitNr /
/form
class NoDoubleSubmitForm {
private int submitNr;
NoDoubleSubmitForm(String id, IModel model) {
super(id, model);
26 matches
Mail list logo
