1. A password (or/and username) that doesn’t contain any numbers
2. MySQL type conversion in conditions – when comparing a VARCHAR column to an INTEGER value it converts VARCHAR to INTEGER, not the other way around.
3. My own database wrapper was trying to be smart and didn’t wrap numeric values with apostrophes

Consider this template:

and something along these PHP lines:

I won’t go into details about mysqlValue(). The important part is that it checks for special cases of NULL, true, false and is_numeric() and runs the rest through mysql_real_escape_string(). Then it inserts all parameters into the template using vprintf().

The problem is with is_numeric(). After being evaluated as a numeric value, ’00′ is entered into the query without apostrophes.

And because any varchar that doesn’t contain a number compared to an integer is evaluated as true the result is a catastrophe.

'abc' = 00 is evaluated as true. 'abc1' = 00 would be false however, unfortunately only few users append a number to their password. If you use 00 for both the username and the password you get authenticated as the first user who didn’t do so.

Check out this false bug report or the related documentation page.

Why you could want to pass numeric values without apostrophes

I wonder myself :-) Here are some reasons I remembered:

• I need to pass NULL in some cases and for that I can’t use %d
• Using apostrophes for integer comparison (1 = ’1′) means unnecessary type conversion that takes time. A small amount of time but still.
• An argument for abandoning the is_numeric() code: Using %d and %s in SQL templates provides a visual clue about what values can be expected there. But then I couldn’t insert NULL values.

So how to fix this mess?

What do you think? Should I remove the is_numeric() test and replace all %d with %s in all SQL templates? Remember that printf("%d", "'123'") will return 0.
Or should I keep the is_numeric() test and rewrite vulnerable queries to use for example CAST:

Update 2010-01-18: I added the real reason for wanting to preserve %s in the template.

Update 2010-01-20:
Unfortunately, what I thought to be a solution (CAST(%s AS CHAR)) has another flaw – strips leading zeroes from the username / password which results into authentication failure.
So dear reader, any ideas?

We all develop (and test) on one computer and deploy to a different computer to make the changes live. Having to run the application in two different environments brings a challenge of using different configuration based on where the application runs.

Multiple configuration files

I started by having two configuration files, one for my dev box and another for the production server. They were named the same and I had one on my dev box and one on the server. Each deployment though, meant that I had to be careful not to overwrite the server file with my local copy. That ruled out using a simple synchronization script like lftp or WinScp.

The simplest solution is to name the configuration files differently and upload them both to both servers. All right, even simpler is to have a single configuration php file and define different values using if/else but that can quickly get out of hands as the number of variables grows.

If you need to upload to more production servers (more than one customer) you need to use some more sophisticated deployment script (Ant?).

Let’s return to the simple solution for now. You need to find a piece of information that can be used as a computer identifier and use it to choose the right set of configuration data.

$_SERVER['SERVER_NAME'] & $_SERVER['SERVER_ADDR']

You can use these two for most situations. I develop on my workstation and I have set up domain name based web hosts (C:\xampp\apache\conf\extra\httpd-vhosts.conf) using fake domains (C:\WINDOWS\system32\drivers\etc\hosts).

Using $_SERVER['SERVER_NAME'] works when you know it up front but sometimes your client is going to choose it just before launching the site. Or he decides to change it later on. Not a big deal but I don’t like chaos.

$_SERVER['SERVER_ADDR'] is also fine but don’t forget to change it when your production server’s ip address changes. Not an issue if you use just two computers with 127.0.0.1 and “else”.

Running scripts locally

Sometimes you need to run a script locally as an extra level of security. Say you run a cron job and you don’t want public to mess with it by running it off schedule. So you run it as http://localhost/tadada.php and check for SERVER_NAME/ADDR to make sure it was indeed run that way. But then your cannot use it for picking the right configuration set.

getenv(“COMPUTERNAME”) to the rescue

This value is unlikely to change during the lifetime of your application and doesn’t change based on the way you run it. The drawback is that not all servers define this variable so you may have to seek a different computer identificator.

What is your way of dealing with configuration sets?

2008-11-15 minus 2008-10-01 can’t be one if you’re calculating rent. It must be 1.466…

Note: end date is not inclusive.

or more robust version:

If you ever wanted to have month number without the leading zeroes, here’s how:

or even a cooler way:

(because you can use almost any PHP function as Smarty variable modifier, just solve the parameters-order problem)

Question

Got any better solution? Tell me about it!

So here’s what I use:

When I want to report something I call:

Then in your main file you run this:

Include this into template (preferably the part that is included into every template):

And then in css, define all message types:

Question

Do you use something like this or something more clever? Share your wisdom :-)