VPS business hosting starting at $29.95/24/7 premium technical support

Funny php bug due to hashing and is_numeric

So I was working on an automation project and was testing the api to upload entitites.

I used get parameters to send data and wrote a wrapper on server to process that. I used hashes (part of hashes to be precise) to identify the requester instead of using real names.

some name came up with hash

12200e7973d0eecd8d75da83e816783496e440e22210ee72cb5cf37f7989a8ff

I was using first 10 characters of this has which happen to be

12200e7973

If you notice, only alphabet is “e” and all others are digits.
But at the same time this is a number in scientific notation
just the way 1e3 is 1000 because of exponentiation involved. My partial hash string was also being converted and was close to infinity.

My api at the backend was checking the given parameter with is_numeric and in this case, my parameter “12200e7973is 100% numeric (EVEN IF I WAS STORING IT AS A STRING).
Hence my script was failing to save correct data and a major column was left empty in the tables.

This was another blunder by me at programming, but you can easily fix it if you use is_int instead of is_numeric because it would fail type checking via is_int.

Of course I had to edit some code with explicit type casting for other types of api calls which were using IDs instead of hashes to identify the users.

Example code: (This is Not the exact code, not recommended for production usage)

// API ENDPOINT
$user=isset($_REQUEST['user']) ?? $_REQUEST['user'] : 1;
// calling the function with string $user
abc ("xyz",$user);
// Normal code:
$user=$this->getLoggedInUser();
$userid=(int)$user; //explicit casting
//calling the same function with int val
abc("mnop",$userid);

Author: Harshvardhan Malpani

PHP Developer based in New Delhi, India. Working as a freelance web developer providing server deployment, website development and maintenance services.

Leave a Reply

Your email address will not be published. Required fields are marked *