Thanks Yehuda, I think you may have caught it. What happens is that the order entry page returns with an attached pdf copy of the invoice but this is not a redirect, it is the same page that they POST'd. The customer then has to click "finished" to get back to the web site. So I learned something I didn't know. Thank you. John ============================ On Tue, 2021-01-19 at 12:06 -0500, Yehuda Katz wrote: > 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.iliffe@xxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxx > > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|