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.ili...@iliffe.ca>
Sent: 19 January 2021 16:56
To: Apache <users@httpd.apache.org>
Subject: [users@httpd] 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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
--
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.
