Yes, I would agree that it isn't Apache but where else would I find a group of people with extensive experience with web interfaces. Our transaction logs and order entry system show these false orders but that is what I would expect since a perfectly consistent order was placed online. The problem, so far as I can see, is that the requests were replayed externally since we first encounter them as a received packet to httpd. From there our internal systems just processed what they had. What is of most interest to me is whether anyone has ever encountered this sort of situation and if so,how they resolved it. Regards, and thank you for the prompt reply Antony. John ================== On Tue, 2021-01-19 at 18:05 +0100, Antony Stone wrote: > On Tuesday 19 January 2021 at 18:00:11, Ruben Safir wrote: > > > this has nothing to do with apache > > I think that's a somewhat harsh way of putting it, but I do agree > that since > "that page does not show in the httpd log as having been served" you > are > correct, and the problem lies elsewhere. I would suggest looking at > any > database logs for transactions made, to see whether that shows where > the > duplicate order updates came from. > > > On Tue, Jan 19, 2021 at 11:55:41AM -0500, John 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. > > Regards, > > > Antony. > > -- > "Black holes are where God divided by zero." > > - Steven Wright > > Please reply to > the list; > please > *don't* CC me. > > -------------------------------------------------------------------- > - > 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
|