[LRUG] Double submit

[Bruno Bonamin]

We've had to deal with this problem, like 2 days ago.

What we decided to do in the end was having a unique identifier on the
client, and on the create action, if the unique identifier is already
present on a record, we return a 307 temporary redirect, and redirect the
client to the update action.

2015-04-25 1:28 GMT+01:00 Srushti Ambekallu <srshti at gmail.com>:

> The way this manifested for us was iOS Safari not getting a confirmation
> of the first POST because of a spotty connection, and deciding to submit
> again (we disable the button on the first submit, so a double-click is less
> likely for us). As part of the API design, we request the consumers to send
> a unique transaction ID (a UUID, probably). We started out by failing on a
> duplicate transaction, but we’re not moving towards returning the response
> of the first request in the second.
>
> We will probably use redis or something similar to temporarily store these
> responses for a couple of minutes or so.
>
> I mentioned our solution in the context of the API specifically, because
> we have third party consumers of our API, as well as our own single-page
> Angular app and mobile apps which speak directly to the API.
>
> ----
> Thanks,
> Srushti
>
> > On 25-Apr-2015, at 01:12, Andrew Stewart <boss at airbladesoftware.com>
> wrote:
> >
> > Thanks, everyone, for all the suggestions.
> >
> >> Tom:
> >> I assume we’re talking about a POST request that has side effects that
> shouldn’t be repeated, like sending an email or creating a row in a
> database table.
> >
> > Yes, that's exactly what I'm talking about.
> >
> > I hadn't thought of debouncing the side-effects instead of the
> requests.  Presumably one would have to explicitly code this in wherever
> necessary.  In contrast a middleware approach could apply to all POSTs.
> >
> >> Rob:
> >> ... in the event of a double-click, it's the second submission that the
> user will actually see. If you're showing something useful on the
> confirmation page (even just the confirmation itself), you don't want to
> lose that in favour of a validation message.
> >
> > That seems like a fairly crucial point – does it always hold?  No matter
> whether we somehow ignore the second POST or debounce its side-effects, we
> want the user to see the result of the first POST.
> >
> > I think I'll experiment a little and see how things shake out.
> >
> > Bon weekend!
> >
> > Andy
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> > Manage your subscription:
> http://lists.lrug.org/options.cgi/chat-lrug.org
> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>



-- 
Bruno Bonamin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150425/add33f2f/attachment-0003.html>