Would this be proper usage of mysql_real_escape_string()?

Pikachu2000

For example, if I were inserting these into a database later in the script:

$address = mysql_real_escape_string($_POST['address']);
$city = mysql_real_escape_string($_POST['city']);
$state = mysql_real_escape_string($_POST['state']);
$zip = mysql_real_escape_string($_POST['zip']);

Also, is there a different syntax when using mysql_real_escape_string() on integer, float or other variable types?

Piranha

That seems to be an ok use of it. I suspect that you mean to use it like this:

 $address = mysql_real_escape_string($_POST['address']);
$city = mysql_real_escape_string($_POST['city']);
$state = mysql_real_escape_string($_POST['state']);
$zip = mysql_real_escape_string($_POST['zip']);

$sql = "INSERT INTO table (address, city, state, zip) VALUES ($address, $city, $state, $zip);";
$result = mysql_query($sql);

If that is how you mean to use it then it is ok. But you could use sprintf as well:

$sql = sprintf("INSERT INTO table (address) VALUES (%s);",
    mysql_real_escape_string($_POST['address']);
$result = mysql_query($sql);

When you have integer, float or other types you can basically handle it 3 ways:
1. Use mysql_real_escape_string as if it was a text string. It is simple since you do the exact same thing to everything, but if the string is not formatted right then it might cause problems.
2. Check it some other way, as an example check if it is an integer or not. Pretty simple to do, at least with integers. But you have to make sure to do it every time to avoid problems.
3. Do both of the above.
I try to do both using methods. By using methods I can add for example trim as well, and don't have to remember doing all the steps all the time.

Roger_Ramjet

Just use the best partice function from the manual, it checks for magic quotes and numbers as well as doing the escaping on strings.

Pikachu2000

I thought that would work, but wanted to be sure. Sometimes the PHP manual is a bit lacking in verbosity for people with as little experience as I have.

MarkR

Checking for magic quotes is important - just have your application refuse to work if they're on, as data corruption will definitely happen otherwise.

Mark

NogDog

MarkR wrote:
Checking for magic quotes is important - just have your application refuse to work if they're on, as data corruption will definitely happen otherwise.

Mark

Please explain with references and/or empirical proof. I've used the pattern suggested on the [man]mysql_real_escape_string[/man] page of using an if(get_magic_quotes_gpc()) statement to run stripslashes() if needed, and have never run into a "data corruption" issue when doing so on systems which do have magic_quotes enabled.

MarkR

What you're proposing is a complicated hack to work around magic quotes.

Of course, you can avoid this data corruption with a correct workaround, but most that people refer to are incorrect.

Also what is frequently overlooked, is that sometimes you don't want to put data into a database, instead do something else with it (or as well).

In this case, you would also need some hackery.

Moreover, the usual foreach trick with $POST etc, almost always overlooks the fact that $POST can contain arrays.

It's simply more code that I don't wish to maintain in my apps, therefore I don't bother. My code doesn't even attempt to work with magic quotes, and that's the end of it.

Mark

NogDog

MarkR wrote:
What you're proposing is a complicated hack to work around magic quotes.

Of course, you can avoid this data corruption with a correct workaround, but most that people refer to are incorrect.

Also what is frequently overlooked, is that sometimes you don't want to put data into a database, instead do something else with it (or as well).

In this case, you would also need some hackery.

Moreover, the usual foreach trick with $POST etc, almost always overlooks the fact that $POST can contain arrays.

It's simply more code that I don't wish to maintain in my apps, therefore I don't bother. My code doesn't even attempt to work with magic quotes, and that's the end of it.

Mark

Understood - I guess I just seldom have the luxury of (a) having the permission and authority to control server configuration/settings and (b) being sure the software I create will always be used under any specific configuration.

MarkR

In order to be sure your application continues to function under many different configurations, you must continue to test it under those configs.

If those configs are more than one, I find that unacceptable, however I can imagine situations where you have multiple test servers / virtual hosts for testing the application under different configs.

You could reasonably, set up an automated tester which deploys the app in lots of different configurations and runs the test suite on each one in turn to be (reasonably) sure that it will work on different setups.

I imagine that people who make PHP apps for resale / redistribution have to do this, however, I don't. All my apps only run on the configuration they were designed for, which I mandate for the hosting (In most cases I host it too so it's not a major problem).

This is effectively a problem of PHP- there are simply TOO MANY php.ini config options (not to mention compile time ones) too take account of. Testing every possible combination is not even feasible under the setup described above, some shortcuts will be necessary.

This is similar to Win32 software, for example, where many developers have whole networks of machines with different releases of Windows for automated testing (How many versions of Vista are there? And how many languages are they all available in?)

Mark