When a Language “Feature” Becomes a Bug

I recently had to transpose a PHP script over to Ruby for inclusion in an app I’m building, and in doing so I discovered a “fun” quirk.

The script is used to retrieve tracking information.  Part of the authentication routine is the generation of a SHA1 hash consisting of vendor_id + vendor_key + customer_order_number which is passed in with the request.

Pretty typical, right?

Well, in this case, part of the vendor key looked something like this: “kK[))6U>$W&}Y{Sm” (PHP people, see any issues with this string?)

$key = "kK[))6U>$W&}Y{Sm";
echo $key;
"kK[))6U>&}Y{Sm"

The answer is that PHP interprets $ as the beginning of a variable name, so in this string the $W is actually treated as a variable.  Because $W isn’t defined anywhere, it is simply omitted, so that part of the key is rendered as “kK[))6U>&}Y{Sm” without the $W.

This wasn’t caught by the service because they are also using PHP and when they create the SHA1 hash on their end for verification, the $W is also omitted and everything matches up.

Fast forward to me sending the request via Ruby, which treats $W just like regular characters, so my hash doesn’t match and the request fails.

It took me a few to sort out what was going on, eventually I just put print/echo statements line by line in both scripts to see what was going on and that’s when I noticed the PHP rendered key was a few characters short!

Also, I’m sure this is purely coincidental, but I bet that there are other vendor keys that have hidden PHP variables in them.  As long as they stick to using PHP, it’ll work…

TL;DR:  If you are going to generate keys, stick to alphanumerics please!  Ain’t nobody got time to figure out if your fancy key contains hidden variable syntax in the myriad of popular languages.

Advertisements
Tagged with: , , ,
Posted in Fun times, Programming

On a stone for three years

On a stone for three years

“Ishi no ue ni mo sannen” – On a stone for three years

When I started my business, things went ok at first. But after about 6 months, it started to get rough and I was thinking about bailing out and going back to working for someone else.

At that time, my mom told me of a Japanese proverb she heard. The gist of it is that “In order to wear a seat into a large stone, you must sit on it for 3 years.” — in other words, anything major takes time and patience before you see results. In a world of instant everything (text messages, cable internet, 24 hour news, etc) this is a strange concept to most people (including me). The idea that anything can take “years” is crazy!

Inspired by this (and with the loving support of my wife and family), I stuck with it. It took a few more years, but I finally sold my business in January and got hired on as a salaried employee to continue to run it. So now I’m getting paid to work on what my partner and I spent years building, which is amazing.

During those intervening years, this proverb became enough of a rallying cry that mom actually got it tattooed on her back — a pretty amazing show of support!

I decided it was time that I did the same.

I love you Mom — thanks

Tagged with: , ,
Posted in Personal

Algorithm Optimization and the Monty Hall Problem

Optimizing an algorithm is important, both for real-world applications as well as to improve your problem solving skills. However, as computer hardware improves, most people end up neglecting this skillset in favor of a lazy approach since the computational time difference may only be a few seconds. I have been working through problems on Project Euler and have found myself falling into this trap. (Of course, there are problems where a brute force approach is perfectly acceptable, especially if there’s not a closed form solution. More on this later.)
Read more ›

Posted in Alogrithms, Fun times, Optimization, Programming