MySQLi or MySQL, this is the question

As of PHP5, a new improved version of MySQL connector is available. It’s called MySQLi, which stands for “MySQL Improved”. I had to think a lot about what the “i” stands for, but it seems that the guys (or gals) who developed the extension has the same, endless imagination as the PHP developers has.

So, a few words about MySQLi. The first improvement is that it’s object oriented (OO) so it’s extremely easy to use in OO PHP codes. It can be used in the traditional way too, but its real power hides in the OO.
In the standard MySQL queries every should be escaped using mysql_real_escape_string(). This can be a tiny drawback as every single bit in a script will reduce execution time. On the other hand, MySQLi escapes every variable from a query automatically.
Did you try to connect to the MySQL server on secure connection ever? You can’t. It doesn’t support it. With MySQLi you can use secure connection to connect, this means for you increased security.

So, what’s the verdict? MySQLi or MySQL

I say, if you have time and you want to write an OO application, choose MySQLi. This if you develop new application from scratch and you have time to figure out how to use it.
To switch an existent well-designed application on the other hand I don’t recommend MySQLi. While the performance of MySQLi is way better than MySQL’s in some situations, running common queries with MySQLi will not increase your application’s performance.

Filter your variables easily but like a pro!

How painful input validation is! Think about all the possible threats, combination of threats… think with the users’ mind. It’s a pain. And usually who can write scripts which filters effectively the user inputs is considered a pro, without hesitation. Just because it’s hard to do it.
Take the following scenario: you have a text-field which accepts text as user comment. You don’t want to let the user to use HTML in the comment box, and definitely not to allow the user to put javascript in the comment.
So how do you sanitize the string you get? It’s a long and hard way. You would use RegExp to exclude some entities then some php inbuilt functions to encode the remaining or even better to strip tags.
I show you an easier way:

filter_var(’<script>alert('Hello');</script>', FILTER_SANITIZE_STRING);

Done, the <script> tags will be stripped so the string will arrive in the database as alert(’Hello World’).
There are many available filters, just to mention the most interesting ones:

• FILTER_SANITIZE_EMAIL — it sanitizes email address, strips characters which are not in conformance with the applicable RFC (link)
• FILTER_SANITIZE_URL — whether the URL from the variable is in conformance with the applicable RFC (link)
• FILTER_VALIDATE_IP — whether if the input is an IP address or not

I recommend using the filter_var() function and its filters for two obvious reasons: it saves you a lot of headaches and saves you time. Even though the filter_var function was introduced only in php 5.2 the function is extremely useful and gives another reason for you of why to upgrade to php5

For a complete reference please check php.net.

Additional tweaks to tighten php

Believe me or not, the resource limiting of PHP can also be an enormous security factor.
Take this scenario: Mr. John Hacker managed somehow to upload to your server a script, let’s say an IRC bot which eats up computing power and RAM. Your server became inaccessible due to the running script, who your regular users blame? You, of course, who else?
Php has some very neat settings you can tweak in order to limit its memory usage, to expose what version of php you are using or not, and others.
Let’s start from the beginning:
asp_tags and short_open_tags, whether to allow the use of asp-like tags like “<%” and short open tags like “<?” instead of “<?php”. I usually set these to off, for one reason: I usually know I set them to off thus I’m not trying to use them in the scripts, but others don’t know. If they manage to upload a script containing these tags it will be much likely useless for them as PHP won’t do anything with them.
expose_php if set to on, will append to the server signature the PHP version you are using. If you didn’t upgrade yet to the latest php, you should set it to off, else it’s up to you what you do. I like to set it off, let’s not allow others what version the server runs.
memory_limit, this is a nice one and you should tweak it to extreme. You can set how much memory would you like to allocate for PHP. If your scripts are not memory eaters, this should be a low value, if they are, a higher value. You can also disable the directive by setting a value of -1, but be aware that with -1, PHP can use as much memory as it wants. I learned that the golden middle is 32, try first that value and if everything is running well, leave at that value.
register_globals, the black sheep :|. Whether to register the $_ENV, $_GET, $_POST, $_SERVER and $_COOKIE variables as global variables. This is covered in too much articles already, i won’t explain why to set it OFF. If you rely on it, stop doing so, learn how to not rely on it or give up coding, period.
file_uploads and upload_max_filesize, whether to allow or not file uploads, and if you allow, what’s the maximum filesize you would like to accept via the HTTP request. The file upload is pretty useless to have it enabled if you don’t use file upload scripts, so if you are not using disable it. Why let Mr. John Hacker to put file-upload scripts on your server?

And these were all the settings I wanted to cover in this post. Consider using them, think carefully before allowing something and before setting something, always.
Here are the settings I recommend:

asp_tags = Off
short_open_tags = Off
expose_php = Off
memory_limit = 32M
register_globals = Off
file_uploads = Off
upload_max_filesize = 2M

Again, much likely others would do it in another way, that’s my way, feel free to use it or not

Migrating from php4 to php5? Pros and cons

You think it’s hard? You think you will brake codes?
Why? Probably cos everyone told you so. I tell you something else: You have nothing to fear of.

Maybe the title is a bit unrelated to the post as I can’t seem to find a valid and justified con against it.
Anyway, some thing you should know: PHP 5 was released cos it contains dozens of fixes, upgrades. It wasn’t released cos the team which manages the project had a godly touch or they were drunk and when they woke up all they knew was they have to release a new PHP. No. There was a very good reason, and just for the matter of the argument, when something is free anyway, why wouldn’t you upgrade to a better, improved version? Huh?

The guy who I work with day-by-day, and probably my best friend as well, will say “don’t fix what is not broken”. I say, if something contains bugs, isn’t that thing broken?

So, as I said, you have nothing to fear of, much likely your code will work on the new platform as well, sincerely, when I upgraded to PHP 5 none of my scripts stopped working and there are a few hundred of separate scripts, but just to be sure, let’s check some things.

First of all, i don’t know if you know or not, there are some reserved words you can’t define in your scripts as variables or constants. That’s clear I guess, the “why don’t” has a simple answer… well, two: the first is, cos this is what the developers of PHP said, secondly cos why would you want to define a constant which was previously defined in the PHP core as a function. For example, “echo”, would you redefine it as a constant? I hope you wouldn’t. Also, the same applies to reserved words like “FALSE”, “TRUE”, “NULL”, etc. as these are reserved constants. Have a look on php.net on the reserved keywords list, well, table (link). Also, someone asked me of why “parent” and “self” throws errors when using them in scripts as (re)defined constants. Well, they are inbuilt classes, simple.
Another major change is that array_merge() accepts only arrays. This should be obvious anyway but as of PHP5 it returns NULL. There are some other changes as well, php.net has a more comprehensive list here (link).

And probably that was all you feared of. Really.