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 Carman <[EMAIL PROTECTED]>
wrote:
> 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 behavior
> to be added to a form, but I don't know how that would work (getting
> the value submitted in the behavior and causing a validation error).
> Thoughts?
>
> > 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]
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
