Synchronizer token

[Jacques Le Roux <ja...@les7arts.com>]

Hi,

I remember having seen discussion and even implementation of a mechanism (javascript function submitFormDisableSubmits in rev.
525629) to avoid double posting.
Looking in Nabble I found only this thread http://www.nabble.com/Dev---Double-posting-in-service-and-entity-ECAs-tf1196643.html
which is not really related.
I read also in http://www.opensourcestrategies.com/ofbiz/ofbiz_webapp_cookbook.txt that we should use
    <response type="request-redirect" ...
But the explanation is not clear to me. Also I find this solution a bit tricky, I think this should be always done without having to
worry about.

So I wonder why OFBiz is not using the Synchronizer token pattern as described in "Core J2EE Patterns" from
http://docs.ofbiz.org/display/OFBIZ/OFBiz+Related+Books ? The book gives an example of how it's done in Strut for instance.

Jacques

Re: Synchronizer token

[Jacques Le Roux <ja...@les7arts.com>]

Thanks for comment David,

I have not time yet to do the implementation but that's typically the kind of thing I want to do... later...

Jacques

De : "David E Jones" <jo...@hotwaxmedia.com>
>
>
> Jacques Le Roux wrote:
> > Hi,
> >
> > I remember having seen discussion and even implementation of a mechanism (javascript function submitFormDisableSubmits in rev.
> > 525629) to avoid double posting.
> > Looking in Nabble I found only this thread http://www.nabble.com/Dev---Double-posting-in-service-and-entity-ECAs-tf1196643.html
> > which is not really related.
> > I read also in http://www.opensourcestrategies.com/ofbiz/ofbiz_webapp_cookbook.txt that we should use
> >     <response type="request-redirect" ...
> > But the explanation is not clear to me. Also I find this solution a bit tricky, I think this should be always done without
having to
> > worry about.
> >
> > So I wonder why OFBiz is not using the Synchronizer token pattern as described in "Core J2EE Patterns" from
> > http://docs.ofbiz.org/display/OFBIZ/OFBiz+Related+Books ? The book gives an example of how it's done in Strut for instance.
>
> Note that all of the solutions to this are a bit tricky and none of them are perfect. The request-redirect isn't a perfect
solution but helps because the first round-trip is faster and hopefully the browser will clear the page, but the main benefit is
that if the user goes back unless they use a history or go back twice real quick then they won't get back to the form.
>
> The "synchronizer token", really more of a singleton type of thing, is meant more to prevent multiple submits. These can be really
annoying though if not implemented correctly, and there always seem to be little quirks with them (in spite of a basic
implementation being fairly simple). The client side JavaScript can be annoying too if a packet is dropped in the request or
something causes the page to not load.
>
> Anyway, I think the main reason for no per-form singleton key being in place is that it just hasn't been implemented yet to
automatically happen. Generating a key and putting it in the session in a Set of valid keys (the Set is necessary instead of a
single value because they might have multiple windows/tabs open in the app or other various scenarios that make it annoying without
the Set) and then removing it once the form is submitted and returning an error if the key for the form isn't there isn't all that
hard. If the form widget and a service event handler are used we can do it automatically in those places (for FTL forms and custom
event handlers it would have to be manually checked).
>
> -David

Re: Synchronizer token

[David E Jones <jo...@hotwaxmedia.com>]

Jacques Le Roux wrote:
> Hi,
> 
> I remember having seen discussion and even implementation of a mechanism (javascript function submitFormDisableSubmits in rev.
> 525629) to avoid double posting.
> Looking in Nabble I found only this thread http://www.nabble.com/Dev---Double-posting-in-service-and-entity-ECAs-tf1196643.html
> which is not really related.
> I read also in http://www.opensourcestrategies.com/ofbiz/ofbiz_webapp_cookbook.txt that we should use
>     <response type="request-redirect" ...
> But the explanation is not clear to me. Also I find this solution a bit tricky, I think this should be always done without having to
> worry about.
> 
> So I wonder why OFBiz is not using the Synchronizer token pattern as described in "Core J2EE Patterns" from
> http://docs.ofbiz.org/display/OFBIZ/OFBiz+Related+Books ? The book gives an example of how it's done in Strut for instance.

Note that all of the solutions to this are a bit tricky and none of them are perfect. The request-redirect isn't a perfect solution but helps because the first round-trip is faster and hopefully the browser will clear the page, but the main benefit is that if the user goes back unless they use a history or go back twice real quick then they won't get back to the form.

The "synchronizer token", really more of a singleton type of thing, is meant more to prevent multiple submits. These can be really annoying though if not implemented correctly, and there always seem to be little quirks with them (in spite of a basic implementation being fairly simple). The client side JavaScript can be annoying too if a packet is dropped in the request or something causes the page to not load.

Anyway, I think the main reason for no per-form singleton key being in place is that it just hasn't been implemented yet to automatically happen. Generating a key and putting it in the session in a Set of valid keys (the Set is necessary instead of a single value because they might have multiple windows/tabs open in the app or other various scenarios that make it annoying without the Set) and then removing it once the form is submitted and returning an error if the key for the form isn't there isn't all that hard. If the form widget and a service event handler are used we can do it automatically in those places (for FTL forms and custom event handlers it would have to be manually checked).

-David