Trapped by the IP Trap

I worked on a site recently where the client’s payment processing was not working.  The order was getting reserved in the database, but no details were appearing.  However, payment completed on the processor’s side.

This particular processor operated like PayPal IPN.  First, you add an order to the database.  Then redirect to the processor to collect card details.  Then the processor would call back to the osCommerce cart and tell it to update the order.  The part that was failing was the call back.

Looking in the logs, I discovered that the processor was getting a 302 (moved temporarily) redirect.  Ah ha, I said.  Something in osCommerce is redirecting the processor.  So, all I need to do is add code to tep_redirect to log from where it was called and with what parameters (PHP provides a function called debug_backtrace for this purpose).  Then I can go through the logs and find what code is doing the redirect and change it.

Unfortunately, that didn’t work.  Redirects were logged, but not the problematic one.  My next step was to add logging steps to checkout process and log the referrer.  The referrer that I wanted was the payment processor.  No entries.  Finally I put a log message above the include for application_top.php.  Woo hoo!  A log message.

My next step was to scatter log messages throughout application_top.php.  On the second iteration, I had narrowed it down to a call to the IP trap file.  Looking in IP Trap, I see that it does manual redirects, bypassing tep_redirect.  Looking at the reasons to redirect, the one that sticks out at me checks to see if the user agent is blank.

The user agent is the string that the browser sends to tell the server what kind of software it is.  Since the first browser was called Mozilla, subsequent browsers have said that they were Mozilla compatible.  For example, the IE 8 user agent string on Vista is “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)”.  Bots often send weird user agents.  For example, “Googlebot/2.1 (+http://www.googlebot.com/bot.html)” is a user agent string that Google’s search spider uses.  In normal browsing, the user agent will never be blank, because all browsers send a user agent by default.

Some number of cracker scripts have used blank user agents.  Presumably they do this to make themselves harder to identify.  The payment processor presumably uses the same logic.  The fix for this was not difficult.  It was almost entirely troubleshooting difficulty.  Trapped by the IP trap.