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