Forum Moderators: buckworks
We've checked our logs, and there was definately activity between 4:32 PM and 6:11 PM, as if the customer somehow browsed around and resubmitted the order - but if that were the case, it would have opened a new session id and a new cart.
The only thing different from the other orders over the last two years is the client was Safari. Has anyone seen anything like this?
Why it was 99 minutes later I can't explain.
The order that was posted to the admin system, do you know if it was the 1632 or the 1811?
Order Date: 06/02/2007 16:53:48 Last Modified: 06/02/2007 18:41:56
I checked our logs, this client (safari, IP, etc) did all the browsing before and after. I'd be suspicious but it's never happened before or since . . . just weird.
This is a dedicated server (not VPN) with a few other well-controlled projects on it.
Personally, if it's a one off, it's probably not worth your time. Put some more logging in somewhere, and see if it happens again.
[edited by: rocknbil at 5:19 pm (utc) on June 7, 2007]
It is custom programmed. There is nothing wrong with the cart software. *something* caused the exact same order, session id, and contents to post twice. Since it was the same sessionid, it updated the order. It posted twice to the cart, generating an email response, which posted a second request to the gateway, generating a new unique ID there. We've checked logs, it is not an injection attack, this all came from the same IP and client as if the customer's client generated a second request.
Maybe the customer was browsing around and went stumbling through their history page looking for something and happened to click on the submittal page.
I'd absolutely agree with you - except -
1. Once an order is complete, cookies are cleared. They are blank values. Any new cart additions or cached page submits prompt the creation of a new session id, and a new cookie is set.
2. As I mentioned, when an order is complete the database entry is altered so it prevents it from being "added to" publicly. One of those is an order complete date. If this field is populated it can't possibly be added to.
3. Session ID's are cookie-sets only, they are not carried in pages as hidden variables. This has the down-side of order loss if cookies are disabled (the user is warned they can only order one item at a time in this state) but it's a risk I'd rather take.
The first two mechanisms prevent duplicate orders from double-clicks, refreshes, and other user problems. I've thoroughly tested this, if you back-button and even to try and update a cart after completing it, you get "this order has been completed, log in to the customer area to view it."
How are you creating the session ID, and when is it reset?
The session id is created out of a combination of IP address, time, *and* a random 8 digit number. It is next to impossible to create the same session id unless you somehow send two simultaneous requests from the same IP at the precise same millisecond. Upon completion of an order, the cookies are cleared.
The only reason I bring this up for discussion is the two were posted an hour and a half apart. It's as if the server was rebooted and "thought" it had a process to complete, but I'm on this server all day, every day, no reboots or other oddities ocurred during that time. It just has me baffled. Since then I've thrown a few more test orders at it, tried some remote command-line injection tests, I just can't duplicate it. :-(
No idea how this could have happened, so I refer to my earlier post:
Personally, if it's a one off, it's probably not worth your time. Put some more logging in somewhere, and see if it happens again.
