It is likely that the user still has the browser tab open and it refreshes for some reason, or their browser crashed and reopened, or they use a session restore tool when they reopen the browser - all of these could cause an exact duplicate request. You might want to look into the Post-Redirect-Get pattern.
In a nutshell: When a POST request completes without any errors, never return any output except a redirect to a completion page. The browser will make a new GET request to this page and any POST data will not be included. This will prevent a form that was submitted successfully from ever being resubmitted accidentally. On Tue, Jan 19, 2021 at 12:00 PM John <john.ili...@iliffe.ca> wrote: > Since the beginning of 2021 we have encountered two online orders and > possibly a third, where the customer denies making the order and the > httpd log seems to confirm that. > > In each case, the person made an order and a day or more later a > second order was placed for the same item and carrying the same credit > card information. Since everything looked valid and the delay > bypassed our duplicate order check, the order was accepted. > > Some background: a customer can connect to our catalogue and move > around untracked for as long as they want until they decide to place > an order. At this point there is only one path to follow to enter > address info, credit card, etc. This ends with a summary of the order > and if they click to proceed, it POST's the server order processor > with the relevant info causing the credit card to be charged and the > order to be entered. In total 3 scripts must be processed in the > correct order. > > I scanned for the customer's IP in the httpd access log in each case > and found that when they made the valid order they were on our > catalogue and followed the correct path to place the order, confirming > it as expected. > > BUT, and here is what I am having trouble understanding, for the > invalid order ONLY the last request was logged as received by httpd. > It shows the correct source (ie the page that should have resulted in > an order) yet that page does not show in the httpd log as having been > served. In one case, NO other page was served to that customer on > that day ahead of the received order, at least judging from IP > addresses in use. > > So what I appear to be seeing is a replay from the Internet which I > find hard to accept as real. Has anyone ever seen this before and if > so what did they do to resolve it? The only other possibility that I > can think of is that their browser cached the page and re-transmitted > it. (a violation of the HTML standard I think for a form page). > > The environment is Apache 2.4.25 on Fedora using php-fpm. > > Thanks in advance and apologies for the length of this post. > > John > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
