[Catalyst] The old double-post issue

Wade.Stuart at fallon.com Wade.Stuart at fallon.com
Fri Sep 22 17:45:51 CEST 2006

catalyst-bounces at lists.rawmode.org wrote on 09/21/2006 05:57:11 PM:

> On Thu, Sep 21, 2006 at 05:04:38PM -0500, Wade.Stuart at fallon.com wrote:
> > But why are you returning an error page,  doesn't the fact that the
> > no longer is valid mean that the form has already been submitted
(return a
> > oops this form has already been submitted page)?
> The token is still valid.  The test for the token and its update are
> not atomic, so a second request can get in before the session is
> updated to reflect that the token is invalid.  It's a race condition.
> So, it would be helpful to move to a token system where the test and
> invalidation are atomic (like storing the token in the database and
> checking rows deleted).
> If I submit a form and wait, then reload then, yes, it will tell me
> the form can't be posted because the token is no longer valid.  But,
> by double post, I mean a double-click on the submit button.  It's
> submitting the request, then quickly submitting the same request
> again.

Looking at the code I see that,  I may rewrite or release a new one that is
more atomic -- forcing the token to be marked as soon as possible.

> In that case even returning "oops, page already submitted" still means
> the first request (of a double-post) was processed and the user sees
> no output from that first request.  I see no way around that, except
> the sick idea below.  If you hit submit and then close your browser
> you get basically the same result -- don't see the response.
> > > My code now detects that something doesn't quite make sense and gives
> > > a slightly smarter message.  But, it's not always easy to see a
> > > request and know that it's already happened vs. just is not in a
> > > state where that kind of request is allowed.
> >
> > Does the plugin actually lose its state without a submission? (even if
> > go to another section of website on the same session...)
> The token is stored in the session.  So all that happens is upon
> submission a check is made that the token exists in the form and it
> matches the current one stored in the session.  If so, it is deleted.
> When a new form is created a new token is created.  Someone can't
> really have two windows open at the same time.

This seems like a bug to me,  the token list should be just that.   not a
one off placeholder.  You should be able to have N tabs open on different
forms on the same app/session without each form clobbering the previous
ones token.  Tokens are cheap and specific enough that they should be kept
until used.

> I think I'll move to a system of storing the tokens in the database
> and then it's one token per form and can only be used for one
> submission.  And use cron to remove old tokens.

exactly -- or make the token create function of the plugin tree down and
prune tokens older than config->{timeout}.

> I could be crazy and store the output from first form posting in the
> database and then if another form is posted with that same token just
> redisplay the original page's output.  That sounds like trouble.
> Geeze, if people double click on submit buttons and can get past the
> javascript then they get what they deserve. ;)

That viewpoint is hard to sell to me.  If people double click and I am not
smart enough to catch it I get what they deserve. =)

> --
> Bill Moseley
> moseley at hank.org
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive:
> Dev site: http://dev.catalyst.perl.org/

More information about the Catalyst mailing list