PHP versus ASP

Here is a link dump of some PHP versus ASP discussions that I have run across lately:

• ASP v PHP discussion at Webmaster World.
• A report from someone who switched from ASP to PHP.
• PHP versus ASP.NET via Oracle.
• A rebuttal from the ASP point of view.

And just so java doesn't feel left out:

Can Java CMS match the PHP ones?

Improved Error Messages in PHP 5

Sometimes its the little things that make a difference. If you run the this test program in PHP 4 (tested on 4.4.7):

<?php
function test($arg) {
 echo "talk like a pirate."; 
}
test();
?>

You get the following message:

Warning: Missing argument 1 for test() in /usr/bin/- on line 2

The error message here is reported at the position of the definition of the function, but really the error was in how the function was called. The required parameter to test was not passed. This error can be annoying, forcing you to consult a stack trace to find the actual error location. Something some beginners may not know how to do.

However, if you run the same message in PHP 5 (tested on 5.2.2):

Warning: Missing argument 1 for test(), called in /Users/jeff/- on line 3 and defined in /Users/jeff/- on line 2

Sweet improvement!

One more reason to ditch PHP 4 and go php 5.

PHP: File Manipulation Attack

Some sites currently running on the web today have URLs that look like this:

index.php?page=contactus.html

The "index.php" file then simply includes the "contactus.html" file, and the site appears to work. However, the user can very easily change the "contactus.html" bit to anything they like. For example, if you are using Apache's mod_auth to protect files and have saved your password in a file named ".htpasswd" (the conventional name), then if a user were to visit the following address, the script would output your username and password:

index.php?page=.htpasswd

By changing the URL, on some systems, to reference a file on another server, they could even run PHP that they have written on your site. Scared? You should be. Fortunately, again, this is reasonably easy to protect against. First, make sure you have correctly set "open_basedir" in your php.ini file, and have set "allow_url_fopen" to "off". That will prevent most of these kinds of attacks by preventing the inclusion of remote files and system files. Next, if you can, check the file requested against a list of valid files. If you limit the files that can be accessed using this script, you will save yourself a lot of aggravation later.

PHP: Preventing Cross-site Scripting Attack

Good article summarizing the dangers of Cross-Site Scripting and how to prevent them. Examples are in Perl but the basic message is never trust anything from the browser.

Where cross-site scripting is concerned, particular caution needs to be taken if you allow visitors to your site to add content to it or “echo back” values they’ve submitted (such as a word they’re searching for).

These days it’s better to use PHP libraries like PEAR::HTML_QuickForm or PEAR::Validate to prevent oversights when using regular expressions to validate incoming data.

When you need to allow visitors to add marked up content, the most effective approach is BBTags (common to vBulletin and phpBB) - PEAR::HTML_BBCodeParser can help. “One to watch” in that area is KSES which is an “HTML and XHTML filter”, if you want visitors to be able to use native tags.

PHP: Prevent SQL Injection Attacks

Security of your website information is probably the most important thing. If your database contains valuable data, you might lose your data or your data could be stollen.
Not every web developer has heard about SQL Injection. I know, you will say "Who is going to hack my website?", "Why should anyone hack my website?" or "No one is gonna hack my website".

How SQL Injection is possible?

This is possible through user input ( POST, GET )

With SQL Injection a hacker can retrieve your data, insert, delete, so basicly can do anything with your database.

You need to sanitize input data, before being used in a sql query.PHP has two functions for mysql that sanitize user input: addslashes( older ) and mysql_real_escape_string( recommended ). This function comes from PHP >= 4.3.0, so you should check first if this function exists. Mysql_real_escape_string prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.

This is a customized function I use to sanitize input data before using it into a sql query:

<?php
// this fn will add slash to the quotes

function safeEscapeString($string){
  if(get_magic_quotes_gpc()) {
    return htmlspecialchars($string);  
  } else {
    return htmlspecialchars(mysql_real_escape_string($string));
  }
}
?>

Why is PHP Code Considered Hard to Maintain?

Tobias Schlitt describes Tim Bray's talk at the International PHP Conference. (PDF slides) Tim compares PHP, Java, and Rails along several dimensions. One of those dimensions is maintainability. Tim ranks PHP as least maintainable, Rails in the middle, and Java as most maintainable.

This is not a surprising ranking. After all, Tim is from Sun, and the maintainability complaint is common in Anti-PHP rants. I'm not trying to suggest that Tim is anti-PHP, far from it, it seems. I'm just using his ranking as a spring board to ask questions.

Chances are that your average Java jockey or C scientist's first exposure to PHP is to download one of the popular PHP applications. These are usually the product of some open source mega-project with developers of varying degrees of skill. Our engineer-by-day spends a few evenings with the program. The code is not technically outstanding.

How can something like this be so popular he asks? Yet, the software is successful by definition. Nobody downloads unsuccessful open source applications. The technocrat, heavily invested in his own technical prowess, faced with successful yet technically inferior code experiences cognitive dissonance. The only thing to do is to belittle the successful, but surely offensive code. "I could write better code than this," he says, or "this code sucks," or "this is unmaintainable."

It is easy to dismiss these gripes inside the PHP community. After all, those of us using PHP professionally can write maintainable code in PHP. Ask any programmer and they will tell you, "My code is maintainable." Who writes all of this unmaintainable code, anyway?

Lets take this gripe at face value for a moment. Why is PHP code considered hard to maintain? Is it the language that produces code that is hard to maintain, or is it that the popular ambassadors of the language happen to be programs that are hard to maintain?

Another common PHP sucks complaint is that PHP doesn't scale. When you are talking about traffic, there are all sorts of counter examples for this. Personally, I'm dying to learn the story behind those .php extensions on YouTube. But, this post is not about requests per second.

Another kind of scalability is team size. I think that when some people complain that PHP doesn't scale, what they mean is that PHP doesn't scale to large development teams or large projects. Now we are back to the maintainability issue.

What is it about PHP that makes people think that it is not suitable for larger development teams?

The criticisms of maintainability and scalability generally come from outside the PHP community. But, there is a common complaint from within the PHP community.

It is hard to find a PHP wish list that doesn't include namespaces. It comes up again and again.

Sometimes users request a feature without explicitly making their true desires and intentions known. They say "I want feature X," but what they really mean is "solve problem Y." Good programmers can hear the request for X, but make the jump to solving Y.

When people ask for the namespace feature, the problem they want to solve is integrating code from multiple parties. I wonder if the frequency of this request is a signal of a problem in this department? Perhaps one that requires more than just namespaces to solve? Is the namespace request a proxy for a larger problem?

What is it about PHP that makes it hard to integrate code written by multiple parties, whether they be different developers or different organizations?

PHP vs Ruby on Rails, Part 2

In part 1 we explained how PHP is just a language, yet we never really talked about Ruby, the language in which Rails is written. Ruby is a fun and interesting language in its own right; however, it has gotten a lot more spotlight these days, specifically because of Rails. So, if you are using Rails you’ll be writing Ruby code, and now it’s time to compare some aspects of Ruby to PHP.
For me, the biggest difference between Ruby and PHP is that Ruby is an object-oriented language throughout, while PHP’s object model feels more like an afterthought. In Ruby everything is an object, while in PHP most everything is a native variable type.

I’ve been using object-oriented design exclusively for a few years now, and while I continue to model my PHP web applications with objects, they can be very awkward at times. When this happens I’m usually forced to jump back to procedural programming to do things like iterate over a collection of objects. Iterators, by the way, are very cool in Ruby. For example, in Ruby I can do something like:

employees.each {|employee| employee.give_raise}

That .each statement lets me iterate over the collection and then use the reference between the pipes as a way to perform actions onto the object. In this case, giving each employee a raise.

In PHP few things are objects by default, including collections. Instead, there is a native array type and a bunch of functions that you can pass an array to that do something of interest. For small scripts this doesn’t bother me, but for my bigger projects it’s a real pain. Early on I even considered writing my own array object. I quickly let the idea die when I came to realize I’d have to pass out native array types to the various tools (like Smarty and a number of other PEAR Objects) anyway, as that’s what they knew how to work with.

So those are some of the biggest reasons why I’m starting to prefer Ruby over PHP, but this comparison still has one more part: deployment. What good is an app if you can’t put it onto a production server? In the final installment of this comparison we’ll look at the differences in deploying a Rails app vs a PHP app. See you then.