Buoy in the ocean

Roman K. once helped to maintain a company website that served a large customer base mainly within the United Kingdom. Each customer was itself a business offering a range of services. The website displayed these businesses on a map so that potential customers could find them. This was done by geocoding the business' addresses to get their longitude and latitude coordinates, then creating points on the map at those locations.

Simple enough—except that over time, some of the businesses began creeping west through the Atlantic Ocean, toward the east coast of North America.

Roman had no idea where to start with troubleshooting. It was only happening with a subset of businesses, and only intermittently. He was certain the initial geocoded coordinates were correct. Those longitude and latitude values were stored in a database table of customer data with strict permissions in place. Even if he wanted to change them himself, he couldn't. Whatever the problem was, it was powerful, and oddly selective: it only ever changed longitude values. Latitude values were never touched.

Were they being hacked by their competitors? Were their customers migrating west en masse? Were goblins messing with the database every night when no one was looking?

Roman dug through reams of code and log files, searching desperately for any whiff of "longitude." He questioned his fellow developers. He blamed his fellow developers. It was all for naught, for the problem was no bug or hack. The problem was a "feature" of the database access layer. Roman discovered that the user class had a simple destructor method that saved all the currently loaded data back to the database:

function __destruct() {
     if ($this->_changed) {
          $this->database->update('customer_table', $this->_user_data, array('customer_id' => $this->_user_data['customer_id']));
     }
}

The legwork was handled by a method called update(). And just what did update() do?

public function update($table, $record, $where = '') {
     // snip
     foreach ($record as $field => $value) {
          if (isset($value[0]) && is_numeric($number) && ($value[0] == '+' || $value[0] == '-')) {
               $set[] = "`$field` = `$field` {$value[0]} ".$number;
          }
     }
}

Each time a customer logged into their account via the website and changed their data: if any of their data began with either a plus or minus sign, those values would have some mysterious value (contained in the variable $number) either added to or subtracted from them. Say a customer's business happened to be located west of the prime meridian. Their longitude would therefore be stored as a negative value, like -3. The next time that customer logged in and changed anything, the update() method would subtract $number from -3, relocating the customer to prime oceanic property. Latitude was never affected because latitude coordinates above the equator are positive. These coordinate values were simply stored as-is, with no sign in front of them.

There was no documentation for the database access layer. The developer responsible for it was long gone. As such, Roman never did learn whether there were some legitimate business reason for this "feature" to exist. He added a flag to the update() method so that customers could disable the behavior upon request. Ever since, the affected companies have remained safely anchored upon UK soil.

[Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.