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 > > 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. > > johan > > On Tue, Mar 25, 2008 at 6:19 PM, James Carman <[EMAIL PROTECTED]> > > > wrote: > > > 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(); > > add(new AbstractValidator() > > { > > protected void onValidate(IValidatable validatable) > > { > > if (token == null || !token.equals(validatable.getValue > > ())) > > { > > error(validatable); > > } > > token = null; > > } > > }); > > } > > > > private void regenerateToken() > > { > > token = UUID.randomUUID().toString(); > > } > > > > protected final void onComponentTag(final ComponentTag tag) > > { > > super.onComponentTag(tag); > > regenerateToken(); > > tag.put("value", token); > > } > > } > > > > Would that work? > > > > On Tue, Mar 25, 2008 at 1:11 PM, Igor Vaynberg <[EMAIL PROTECTED]> > > wrote: > > > 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) > > > > { > > > > super(id, new PropertyModel(new ValueMap(), "token")); > > > > setType(String.class); > > > > setRequired(true); > > > > regenerateToken(); > > > > add(new AbstractValidator() > > > > { > > > > protected void onValidate(IValidatable validatable) > > > > { > > > > if (!token.equals(validatable.getValue())) > > > > { > > > > error(validatable); > > > > } > > > > regenerateToken(); > > > > } > > > > }); > > > > } > > > > > > > > private void regenerateToken() > > > > { > > > > token = UUID.randomUUID().toString(); > > > > > > > > } > > > > > > > > protected final void onComponentTag(final ComponentTag tag) > > > > { > > > > super.onComponentTag(tag); > > > > tag.put("value", token); > > > > } > > > > } > > > > > > > > Since wicket already syncs on the session, this should work, right? > > > > > > > > > > > > > > > > On Tue, Mar 25, 2008 at 12:46 PM, Johan Compagner < > > [EMAIL PROTECTED]> wrote: > > > > > 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, James Carman < > > [EMAIL PROTECTED]> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > 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() > > > > > > { > > > > > > protected void onValidate(IValidatable iValidatable) > > > > > > { > > > > > > String submittedToken = iValidatable.getValue > > ().toString(); > > > > > > if (!submittedToken.equals(token)) > > > > > > { > > > > > > error(iValidatable); > > > > > > } > > > > > > } > > > > > > }); > > > > > > } > > > > > > > > > > > > protected final void onComponentTag(final ComponentTag tag) > > > > > > { > > > > > > super.onComponentTag(tag); > > > > > > token = UUID.randomUUID().toString(); > > > > > > tag.put("value", token); > > > > > > } > > > > > > } > > > > > > > > > > > > Here, all you'd have to do is add one of these puppies to your > > form > > > > > > and it'll automatically validate itself. > > > > > > > > > > > > On Tue, Mar 25, 2008 at 10:35 AM, Johan Compagner < > > [EMAIL PROTECTED]> > > > > > > wrote: > > > > > > > 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 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_forgeryfor > a > > > > > > > > summary). > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > hillj2 wrote: > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > is upgraded to wicket.) > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > Like I said, for now this appears to be working. I just > > extend all > > > > > > my > > > > > > > > > forms from this class and implement onSubmitted() with > > the same > > > > > > code I > > > > > > > > > previously put in onSubmit(). The key is putting > > matching unique > > > > > > > > strings > > > > > > > > > in session and in the page instance. On submit, those > > string > > > > > > should > > > > > > > > > match, at which point, the string in session is cleared > > and the > > > > > > form is > > > > > > > > > processed as normal. If another submit comes in, the > > string in > > > > > > session > > > > > > > > > has been cleared so it doesn't match the string svaed in > > the page > > > > > > > > > instance. In the case where setResponsePage is not > > called, > > > > > > > > onBeforeRender > > > > > > > > > resets the token string, so submitting from the > > refreshed page > > > > > > won't > > > > > > > > > register as an error. > > > > > > > > > > > > > > > > > > Our JSP version of this involves putting the token > > string in > > > > > > session and > > > > > > > > > also saving a copy to a hidden field on the JSP page. > > Which I > > > > > > think is > > > > > > > > > similar (although maybe a bit more complex) to what > > Martijn was > > > > > > > > > suggesting. > > > > > > > > > > > > > > > > > > Thanks for all you suggestions. > > > > > > > > > > > > > > > > > > Joel > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > View this message in context: > > > > > > > > > > http://www.nabble.com/Double-submit-problem-tp15957979p16275106.html > > > > > > > > Sent from the Wicket - User mailing list archive at > > Nabble.com. > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]