Trying to understand - was it just the last POST that you were seeing - not the series of posts leading up to that stage of the form process.. In this case it looks as (Yehuda is just saying) that the request is kept in the browser. There are some ways to get around this: (1) never POST and print - always do a full redirect for the user - this takes the "successful post" out of the users history (2) Have a unique ID representing the cart (you probably have a cart ID somewhere for the order) and make sure that the same cart ID is not used twice for payment. This is better to be something like a UUID or similar. Second time payment is attempted on cart with given UUID the attempt is rejected. James -----Original Message----- From: John <john.iliffe@xxxxxxxxx> Sent: 19 January 2021 16:56 To: Apache <users@xxxxxxxxxxxxxxxx> Subject: Replays from Internet [EXT] 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 -- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|