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 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] > >