Mailing List Archive: RE: Replays from Internet [EXT]

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@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-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@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.B?KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB??[??X???X?KK[XZ[?\?\??][??X???X?P?\X?K???B???Y][?[??[X[??K[XZ[?\?\??Z[?\X?K???B

Thanks James.

Yes, all we received was the duplicate POST so far as I can find. The
script that would have initiated that POST was not shown in the log as
having been run. That's what caught my attention.

I have been misunderstanding the html standard since I was of the
opinion that it did not allow a retry on a failed POST and on Firefox
if you try to do that you get "Document Expired - The requested
document is not available in Firefox's cache".

But that doesn't apply to whatever is going on in the background I
guess.

I will make the changes to the script to implement your suggestions.

Thanks to both of you for the replies and pointing me in the required
direction. It is great to be able to get assistance from skilled
people.

John
===================================
On Tue, 2021-01-19 at 17:10 +0000, James Smith wrote:
> 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@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-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org