sorted by: recent | see : popular

Content Tagged with User:marc + PHP

The Setup

Imagine, if you will, the following scenario:

• You design a whole new database schema for your cool new scalable web-application. You’re using MySQL and the InnoDB datbase engine for everything, because your schema is so cool it uses all sorts of foreign keys and transactions and the like.
• You quickly set up MySQL and get your application going with your new schema on your development staging machine.
• You get MySQL up and running on your live server, play around with it for a bit to make sure it’s working, and then set up a my.cnf file with all sorts of caching and security goodies in it.
• You do a backup from your dev machine, restore it to the live server, and ta-daa!!! Your web application is up and running on your live server.

What you might not have noticed, especially if you – like me – have a few thousands rows of data, is that MySQL might have screwed you along the way and not really told you all that clearly.

The Problem

After a few days of operation on my live server, I started to notice a few weird things—foreign keys weren’t being enforced properly, and there were some values in the database that probably shouldn’t have been possible. I furrowed my brows and put it on my list of stuff to investigate.

Well, yesterday, I added a new table to the database, and it went something like this:

mysql> CREATE TABLE Fudgecicles
>(
>  id INTEGER AUTO_INCREMENT PRIMARY KEY,
>  value VARCHAR(255) NOT NULL,
>)
>ENGINE = InnoDB;

Query OK, 0 rows affected, 1 warning (0.10 sec)

Where did that warning come from?

mysql> SHOW WARNINGS;

It is here that MySQL tells me:

+---------+------+-----------------------------------------------------+
| Level   | Code | Message                                             |
+---------+------+-----------------------------------------------------+
| Warning | 1266 | Using storage engine MyISAM for table 'Fudgecicles' |
+---------+------+-----------------------------------------------------+

Augh! No! Bad! Bad, MySQL, Bad! Why on earth would it do that? I didn’t misspell InnoDB or even use “incorrect” casing in the name. There’s nothing wrong with the schema I specified and I’ve done this hundreds of times before.

Well, after some research, I then tried the following:

mysql> SHOW ENGINES;

And MySQL helpfully gave me the following:

+------------+---------+----------------------------------------------------------------+
| Engine     | Support | Comment                                                        |
+------------+---------+----------------------------------------------------------------+
| MyISAM     | DEFAULT | Default engine as of MySQL 3.23 with great performance         |
| MEMORY     | YES     | Hash based, stored in memory, useful for temporary tables      |
| InnoDB     | DISABLED| Supports transactions, row-level locking, and foreign keys     |
| BerkeleyDB | NO      | Supports transactions and page-level locking                   |
| BLACKHOLE  | NO      | /dev/null storage engine (anything you write to it disappears) |
| EXAMPLE    | NO      | Example storage engine                                         |
| ARCHIVE    | YES     | Archive storage engine                                         |
| CSV        | NO      | CSV storage engine                                             |
| ndbcluster | NO      | Clustered, fault-tolerant, memory-based tables                 |
| FEDERATED  | NO      | Federated MySQL storage engine                                 |
| MRG_MYISAM | YES     | Collection of identical MyISAM tables                          |
| ISAM       | NO      | Obsolete storage engine                                        |
+------------+---------+----------------------------------------------------------------+
12 rows in set (0.00 sec)

The InnoDB database engine had been disabled somewhere along the way and I hadn’t even noticed. It is enabled, by default, on the standard Linux and Mac OS X MySQL binaries that I’ve been downloading. So something changed along the way that made this all stop.

Far worse, I then began to worry about my existing tables, all of which we supposed to be InnoDB. Upon executing the following for each of them:

mysql> SHOW CREATE TABLE Fudgecicles;

I would see something like:

| Table       | Create Table
| Fudgecicles | CREATE TABLE `Fudgecicles` (
  `id` int(11) NOT NULL auto_increment,
  `value` varchar(255) NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Sure enough, every single one of my tables was MyISAM, and not the InnoDB it was supposed to be.

The Reason

The problem turns out to be that InnoDB is somewhat finicky about my.cnf settings, and will frequently refuse to operate if settings change in this file in such a way that makes any existing data incompatible with the way it would write new data.

In my case, it turns out that changing the settings for the InnoDB binary data and log file sizes were somehow incompatible with the existing binary data and log files (ibdata1 and ib_logfileX). Upon starting the server, InnoDB finds this inconsistent state and simply refuses to start up. This is the first problem.

The second, and far more serious problem, is that MySQL just switches the database persistence engine on you and only provides a little warning. If you’re loading in thousands – if not tens of thousands – of rows, those warnings are easily lost in the scroll-a-thon that ensues. This is bad behaviour. MySQL should simply refuse to create your table if your selected persistence engine is not available.

The Solution

Fixing this problem involved three parts. The first, and easiest, is to get the InnoDB engine back. You have two choices:

1. You can either revert to the original settings you had for the my.cnf file to remove the inconsistent state that is freaking out poor ole’ InnoDB.
2. You can delete the idbdata1 and ib_logfileX files with the inconsistent sizes, thus removing in a different way the same inconsistent state, and allowing InnoDB to startup with your new (and presumably better) configuration values in my.cnf.

I chose the second method.

You then stop and restart the MySQL database engine, and InnoDB will be back. You can verify that all is well in InnoDB land by executing:

mysql> SHOW InnoDB STATUS;

And you will receive a gloriously long and detailed set of information on how things are going.

Part two of the process involved converting my tables back to InnoDB.

mysql>  ALTER TABLE FishSticks ENGINE = InnoDB;

This proves to be tedious and time consuming, as you cannot simply go from table A to table Z doing the conversion – because of the foreign keys and references, they have to be done in the right order. When one of the ALTER TABLE statements fails, you can find out what happened by re-executing the SHOW InnoDB STATUS command – it will tell you why it wouldn’t convert the table to InnoDB.

But, eventually, I got them all done. It was then that I noticed that none of the foreign keys were set up properly any more.

So, the last step of the process is to re-establish the FOREIGN KEYs. I did this by, for each foreign key in each table I had, executing the following commands:

mysql> ALTER TABLE FishSticks DROP KEY [dead foreign key name];
mysql> ALTER TABLE FishSticks ADD FOREIGN KEY (keyname) REFERENCES Table (fieldname);

The good news is that saving my database and getting back to all sorts of InnoDB goodness only took about an hour in total, for about 30 tables or so.

However, if MySQL had simply reported an error a few days earlier instead of blithely just switching tables types behind the scenes, I might have avoided this whole mess in the first place. Oh well, at least I learned a few neat little commands I can play around with now! Lesson learned!

Here’s to hoping that this article helps some other folks solve the same problem a bit quicker!

For those programmers coming to PHP from other languages, the distinction between the keywords break and continue is quite clear. The former is used to abort loop execution or a switch statement while the latter is used to skip to the top (or bottom) of a loop.

So, despite knowing better, I still found myself spending more time than I’d like debugging the following code:

<?php

  foreach ($daysOfTheWeek as $day)
  {
    switch (strtolower($day))
    {
      case 'monday':
      case 'tuesday':
      case 'wednesday':
      case 'thursday':
      case 'friday':
        $this->processWeekdayData();
      case 'saturday':
      case 'sunday':
    // nobody works on the weekend.
        continue;
    }

   //
   // this keeps getting thrown on saturday and sunday !!! how come?
   //
   throw new InvalidDayException('not a valid day');
  }
?>

The problem?

The continue keyword in a switch statement does not work the same way as in other languages. In PHP, continue and break are synonymous inside this construct:

<?php
  switch ($months)
  {
    // start with vowels
    case 'august':
      break;
    case 'april':
      continue;     // exactly the same as "break" !!!
    default:
      return 'OK';
  }

  throw new StartsWithVowelException('Months with vowels are creepy');

?>

While we are on the topic, these two keywords have a feature in PHP that make them a bit more interesting and powerful than their peers in other languages.

Both can be given a numerical argument when used in a loop that indicates how many loops to continue through or break out of. For example, to abort two loops while in the inner loop:

<?php

  //
  // search through our 2D array until we find $value
  //
  $lowerval = strtolower($value);

  foreach ($TwoDArray as $otherArray)
  {
    foreach ($otherArray as $value)
    {
      if (strtolower($value) == $lowerval)
      {
        // we found the value -- break out of both loops
        break 2;
      }
    }
  }

?>

Similarly, to restart the execution of an outer loop from within an inner one:

<?php

  //
  // verify that each sub array contains the given value
  //
  $lowerval = strtolower($value);

  foreach ($TwoDArray as $otherArray)
  {
    foreach ($otherArray as $value)
    {
      if (strtolower($value) == $lowerval)
      {
        // we found the value -- this one definitely has it.
        continue 2;
      }
    }

    // if we've reached here, then the inner loop doesn't have the
    // value.  ¡aiiee!
  }

?>

PHP has a few quirks that can make programmers from other languages scratch their heads, but you will quickly find that these are very easy to get used to and make the language the wonderfully productive one that it is.

As I sit here watching “The Muppets Take Manhattan” in Spanish in the middle of a Costa Rican thunderstorm, I find my mind drifting back to a recent project where I spent a day debugging a frustratingly annoying problem: A user would visit the web application I was working on, and after a given page was loaded, all of the session data associated with their visit would be suddenly gone. The user would no longer be logged into the site, and any changes they made (which were logged in session data) were lost.

It was driving me crazy. I would sit there in the debugger and go through the same sequence each time:

• Debug the request for the page load.
• Debug the request for the first Ajax request that the page load fired off.
• Debug the request for the second Ajax request that the page load simultaneously fired off.
• Debug the request for the third Ajax request that the page initiated

In retrospect, looking at the above list, it seems blindingly obvious what I had been running into, but it was very late in a very long contract, and I blame the fatigue for missing what now seems patently obvious: A race condition.

For those unfamiliar with what exactly this is, a race condition is seen most often in applications involving multiple “threads of execution” – which include either separate processes or threads within a process – when two of these threads (which are theoretically executing at the same time) try to modify the same piece of data.

If two threads of execution that are executing more or less simultaneously (but never in exactly the same way, because of CPU load, other processes, and chance) try to write to the same variable or data storage location, the value of that storage location depends on which thread got there first. Given that it is impossible to predict which one got there first, you end up not knowing the value of the variable after the threads of execution are finished (in effect, “the last one to write, wins”) (see Figure 1).

Normally, when you write web applications in PHP, this is really not an issue, as each page request gets their own execution environment, and a user is only visiting one page at a time. Each page request coming from a particular user arrives more or less sequentially and shares no data with other page requests.

Ajax changes all of this, however: suddenly, one page visit can result in a number of simultaneous requests to the server. While the separate PHP processes cannot directly share data, a solution with which most PHP programmers are familiar exists to get around this problem: Sessions. The session data that the various requests want to modify are now susceptible to being overwritten by other ones with bad data after a given request thinks it has written out updated and correct data (See Figure 2).

In the web application I was working on, all of the Ajax requests were being routed through the same code that called session_start() and implicitly session_write_close() (when PHP ends and there is a running session, this function is called). One of the Ajax requests would, however, set some session data to help the application “remember” which data the user was browsing. Depending on the order in which the various requests were processed by the server, sometimes those data would overwrite other session data and the user data would be “forgotten”.

As an example of this problem, consider the following example page, which when fully loaded, will execute two asynchronous Ajax requests to the server.

<?php
// race1.php
// part 1
session_start();

//
// We will prime the session data with a simple value here.
// One of the Ajax requests going to race2.php will clobber
// this value periodically.
//
$_SESSION['fudgecicle'] = 'eeeek!';

?>
<html>
<head>
  <title>Race Condition Demo Page</title>
</head>

<script>
/* part 2 */
/**
 *=-------------------------------------------------------=
 * getNewHTTPObject
 *=-------------------------------------------------------=
 * This function is here just to create a new
 * XmlHttpRequest object.
 */
function getNewHTTPObject()
{
    var xmlhttp;

    /** Special IE only code ... */
    /*@cc_on
      @if (@_jscript_version >= 5)
          try
          {
              xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
          }
          catch (e)
          {
              try
              {
                  xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
              }
              catch (E)
              {
                  xmlhttp = false;
              }
         }
      @else
         xmlhttp = false;
    @end @*/

    /** Every other browser on the planet */
    if (!xmlhttp && typeof XMLHttpRequest != 'undefined')
    {
        try
        {
            xmlhttp = new XMLHttpRequest();
        }
        catch (e)
        {
            xmlhttp = false;
        }
    }

    return xmlhttp;
}

/**
 *=-------------------------------------------------------=
 * onLoadFunction
 *=-------------------------------------------------------=
 * We call this function when the page loads, and it starts
 * two asynchronous Ajax requests to race2.php.
 */
var xml1;
var xml2;
function onLoadFunction()
{
    xml1 = getNewHTTPObject();
    xml2 = getNewHTTPObject();

    xml1.open('GET', 'http://localhost/race2.php?req1', true);
    xml2.open('GET', 'http://localhost/race2.php?req2', true);

    xml1.onreadystatechange = handleResponse1;
    xml2.onreadystatechange = handleResponse2;

    xml2.send('');
    xml1.send('');
}

/**
 *=-------------------------------------------------------=
 * handleResponse1
 *=-------------------------------------------------------=
 * This handles the response from the first ajax request.
 * It puts the returned string in the <div> element
 * with th eid 'fudgecicles'
 */
function handleResponse1()
{
    if (xml1.readyState == 4)
    {
        document.getElementById('fudgecicles').innerHTML =
            xml1.responseText;
    }
}

/**
 *=-------------------------------------------------------=
 * handleResponse2
 *=-------------------------------------------------------=
 * This handles the response from the second ajax request.
 * We don't actually care about this, so we just ignore
 * the results.
 */
function handleResponse2()
{
    // we don't care about this response
}
</script>

<!--
     part 3

     This page just executes the onLoadFunction() call and
     contains a single <div> where the result will be
     placed.
  -->
<body onLoad='onLoadFunction();'>
  <div id='fudgecicles'>Waiting for response from Server</div>
</body>
</html>

The code is divided into three main sections:

• The first contains the call to session_start() and opens the HTML headers.
• The second contains the Javascript code to execute the asynchronous requests to the server. The biggest function, getNewHTTPObject() is used to create new objects. The onLoadFunction() is executed when the page finishes loading and starts the ball rolling, while the other two functions are simply used to wait for and handle the responses and results from the asynchronous requests.
• In the final section, we just write out the <body> section of the document, which contains a single <div> element to hold the results and an attribute on the <body> element to make sure that the onLoadFunction() is called when the document finishes loading.

The asynchronous Ajax requests are then made to race2.php and are processed by the following code, which can handle two different Ajax work requests:

<?php
// race2.php

session_start();

//
// if they ask for req1, then just return the current value
// of the $_SESSION['fudgecicles'] data.  If they ask for
// req2, then have this session simulate a bogus value by
//  setting $_SESSION['fudgecicles'] to ''.
//
// NOTE:  the two for loops are to simulate the various
//        Ajax processes doing lots of stuff, and force
//        the processor to interrupt the processes
//        periodically to let the other work.  This helps
//        the race condition occur more.
//
if (isset($_GET) and isset($_GET['req1']))
{
    // waste time
    for ($x = 0; $x < 10000; $x++)
        strpos('asdfasdf', 'tttttttttttttttasdfioap');

    if (isset($_SESSION['fudgecicle'])
        and $_SESSION['fudgecicle'] != '')
    {
        $retString = $_SESSION['fudgecicle'];
    }
    else
        $retString = '(empty)';
}
else if (isset($_GET) and isset($_GET['req2']))
{
    // waste time
    for ($x = 0; $x < 10000; $x++)
        strpos('asdfasdf', 'tttttttttttttttasdfioap');

    $retString = '';
    $_SESSION['fudgecicle'] = '';
}

header('Content-Type: text/plain');
echo $retString;
?>

This PHP script handles the two request types differently, and creates the race condition by having the second request type req1 set the sesion data to ’’. (In a real world application, you might have accidentally had this request set some value you thought was meaningful).

If you install the two files race1.php and race2.php on your server, and then load race1.php into your borwser, you will periodically see that the test string is set after the page is completely loaded, and other times it will be “(empty)”, indicating that the second Ajax request has clobbered the value.

Now that we are aware of this problem and how it can manifest itself, the next question is, of course, how do we solve it? Unfortunately, I think this is one of those problems best solved by avoiding it. Building in logic and other things into our web application to lock the threads of execution (i.e. individual requests) would be prohibitively expensive and eliminate much of the fun and many of the benefits of asynchronous requests via Ajax. Instead, we will avoid modifying session data when we are executing multiple session requests.

Please note that this is much more specific than saying simply that we will avoid modifying session data during any Ajax request. Indeed, this would be a disaster: In a Web 2.0 application, we are mostly likely using Ajax for form submission and updating the state of the user data (i.e. session data) as the data are processed and we are responding to the changes. However, for those requests we are using to update parts of pages dynamically, we should be careful to avoid modifying the session data in these, or at least do so in a way that none of the other requests are going to see changes in their results depending on these session data.

Ajax requests and session data do not have be problematic when used together: With a little bit of care and attention, we can write web applications that are powerful, dynamic, and not plagued by race condition-type bugs.

Got other suggestions or solutions to this problem? Add a comment or mail me, and I’ll update the article.

The RSS feeds on the Chipmunk Ninja site have been changed slightly. For compatibility, the old rss/tech.rss and rss/personal.rss feeds will continue to work, but there are now three new feeds:

I have also fixed up the RSS output, particular the XML headers and the way tags are exposed through the <category> element.

As always, please let me know if there are any problems.

PHP is a sufficiently rich programming environment that it is not common that I truly need to execute external programs on the server on which it executes. However, every once in a while, this situation does come along, and for these, it is important to understand the options that PHP provides, what their differences are, and their relative strengths and weaknesses.

There are four primary choices for executing external programs in PHP:

• The system function.
• The exec function.
• The shell_exec function or its syntactic analogue, the backtick operator, ( ` ).
• the passthru function.

We will first discuss the usage of these three functions in their most basic forms.

The system() Function

The system function in PHP takes a string argument with the command to execute as well as any arguments you wish passed to that command. This function executes the specified command, and dumps any resulting text to the output stream (either the HTTP output in a web server situation, or the console if you are running PHP as a command line tool). The return of this function is the last line of output from the program, if it emits text output.

For example:

// Windows Users replace "ls ..." with "dir ..."
$lastLine = system('ls /Users/marcwan');
echo "<br/>LastLine: $lastLine<br/>\\n";

The output of this command on my system is:

Desktop Documents Download Library Movies Music Pictures
  Public Sites bin blah.php books make1.png make1.tiff media src
  yici1.png yici1.tiff
LastLine: yici1.tiff

The return value of the function will be FALSE if the function completely fails to execute.

In addition to the return value of the system function, however, there is also the question of the return status of the program being executed (just as functions in PHP all have return values (NULL if you don’t explicitly choose one), all commands executed in most operating systems also have return values, typically a 32bit integer value). For those programs you are executing whose return status you wish to know, you can pass a second argument to the system function, which tells PHP where to put this value.

For example:

// define this variable here so that it can actually be used in the system fn
$returnValue = -1;
system('ls /Users/marcwan', $returnValue);
echo "Return Value: $returnValue<br/>\\n";

The output of this program will be:

Desktop Documents Download Library Movies Music Pictures
  Public Sites bin blah.php books make1.png make1.tiff media src
  yici1.png yici1.tiff
Return Value: 0

For most modern operating systems, a return value of 0 is considered a success, and other values indicate failure. Some programs will have a range of values to indicate the exact way in which they failed while others will just return 1 or -1 to indicate that they were unsuccessful.

The exec() Function

The system function is quite useful and powerful, but one of the biggest problems with it is that all resulting text from the program goes directly to the output stream. There will be situations where you might like to format the resulting text and display it in some different way, or not display it at all.

For this, the exec function in PHP is perfectly adapted. Instead of automatically dumping all text generated by the program being executed to the output stream, it gives you the opportunity to put this text in an array returned in the second parameter to the function:

// you define this variable here so that it exists for the call to exec
$output = null;

// Windows users: 'dir c:\\' or something similar
exec('ls /Users/marcwan', $output);
echo "<pre>" . var_export($output, TRUE) . "</pre>\\n";

Once again, on my machine, the following output is printed:

array (
  0 => 'Desktop',
  1 => 'Documents',
  2 => 'Download',
  3 => 'Library',
  4 => 'Movies',
  5 => 'Music',
  6 => 'Pictures',
  7 => 'Public',
  8 => 'Sites',
  9 => 'bin',
  10 => 'blah.php',
  11 => 'books',
  12 => 'make1.png',
  13 => 'make1.tiff',
  14 => 'media',
  15 => 'src',
  16 => 'yici1.png',
  17 => 'yici1.tiff',
)

Of course, instead of just directly emitting this output, we could instead choose to process it and only emit those files with a ’.png’ extension, for example:

foreach ($output as $fileName)
{
  if (strtolower(substr($fileName, -4)) == '.png')
    echo "<br/>$fileName\\n";
}

And once again, you can get the return code from the exec function as follows:

$output = null;
$returnValue = -1;
exec('ls /Users/marcwan', $output, $returnValue);
echo "Return Value: $returnValue<br/>\\n";
echo "<pre>" . var_export($output, TRUE) . "</pre>\\n";

The shell_exec() Function

Most of the programs we have been executing thus far have been, more or less, real programs¹. However, the environment in which Windows and Unix users operate is actually much richer than this. Windows users have the option of using the Windows Command Prompt program, cmd.exe (See Figure 1). This program is known as a command shell.

Figure 1— The Windows Command Prompt

Similarly, Unix (and Mac OS X) users can run a command shell such as sh, bash, or csh (see Figure 2). These are typically quite advanced interactive systems that allow elabourate scripts such as for x in *.png; do echo $x; done to be executed.

Figure 2— bash on Mac OS X

On both Windows and Unix, the commands for the various command shells can be put into files and executed by these programs. On Windows, convention has it that these script file have the extension .cmd while on Unix it is not uncommon to see .sh.

For those sitautions where we want to run these shell scripts from within PHP, we can use the shell_exec function, as follows:

// lists all .bat files anywhere in the system
$output = shell_exec('FOR /R C:\\ IN (*.bat) DO echo %x');   // Windows

// lists all .png files in /Users/marcan only
$output = shell_exec('for x in /Users/marcwan/*.png; do echo $x; done'); // Unix

echo "<pre>" . var_export($output, TRUE) . "</pre>\\n";

On my system this produces:

'/Users/marcwan/make1.png
/Users/marcwan/yici1.png
'

PHP also has a syntactic operator called the backtick operator which does the exact same thing as the shell_exec function. Instead of calling the shell_exec function, you simply wrap the command in the backtick character, `, which is very different from the single quote character '.

// lists all .bat files anywhere in the system
$output = `FOR /R C:\\ IN (*.bat) DO echo %x`; // Windows

// lists all .png files in /Users/marcan only
$output = `for x in /Users/marcwan/*.png; do echo $x; done`; // Unix

echo "<pre>" . var_export($output, TRUE) . "</pre>\\n";

It is worth noting that I avoid this operator at all times as it is not easy to spot in code, and I like potential security trouble spots to be as visible as humanly possible.

The passthru() Function

One fascinating function that PHP provides similar to those we have seen so far is the passthru function. This function, like the others, executes the program you tell it to. However, it then proceeds to immediately send the raw output from this program to the output stream with which PHP is currently working (i.e. either HTTP in a web server scenario, or the shell in a command line version of PHP).

When would this be useful? When you are working with image files and want to execute a program to show or otherwise manipulate these files. A most simple example would be as follows:

/**
 * Windows:
 */
header('Content-Type: image/bmp');
passthru('type c:\\Windows\\zapotec.bmp');

/**
 * Unix
 */
header('Content-Type: image/jpg');
passthru('cat /Users/marcwan/yici1.png');

The result will be an image in your browser. This is extremely powerful if you want to use some programs to resize or otherwise manipulate image files and then just dump the output to the client. There are a number of interesting utilities that come with various JPEG source code distributions that do exactly this and are powerful tools.

Are We Done Yet?

Armed with this basic knowledge, we have a one major thing left to deal with before we go off into the real world and begin using these functions: Security.

For example, the following code is simply a recipe for disaster:

$output = shell_exec('cat /webserver/info/user_files/' . $_POST['user_info_file']);
echo $output

If a malicious user were to set the value of the user_info_file post variable to bob; cat /etc/passwd. The output of both files would now be dumped, which is definitely not in your best interests.

There are two key ways which we will get around this:

1. We will design our web applications carefully for security. If we can design the web application in such a way that only we choose the file names and programs that execution functions work with, we have much less to worry about in terms of security. We can also do our best to isolate any files that we work with and try to limit damage whenever something unexpected occurs.
2. For those cases where we decide that user input is absolutely unavoidable, we will filter the user input extremely heavily and make sure it is as safe as possible before passing it to any of these functions. I always do the following:
   • Absolutely forbid the use of any slash characters, whether it be forward ( / ) or backward ( \ ). I also forbid any user strings from beginning with X:, where X could be a valid drive letter on the system (Windows only, of course).
   • Use the escapeshellarg function to further make the parameters safer. I.e. $output = shell_exec("cat /web/users/info/" . escapeshellarg($processedUserInfoFile));

A way in which we are helped by the operating system is that most web servers operate as a user with restricted permission, and thus can only do things that user is permitted to do.

One last security note we should mention here is that if your php.ini file has safe_mode set to On, then the shell_exec function and analagous backtick operator is not available.

Conclusion

We have covered a lot of ground in this article, but we should now have a solid understanding of the various execution functions available to us in PHP, as well as how they differ. While we should be extremely concerned about the security of running programs external to our web server, we can do so in a reasonably safe and controlled manner, which can only be a good thing for our web applications and their customers.

—

¹ It is worth noting that dir, type, and many other commands on Windows are not programs, but actualy commands built into the cmd.exe program. Fortunately the system execution functions are smart enough to know to execute cmd.exe for you if you ask to execute one of them.

I never really intended for it to spiral out of control like that. I had just started writing my book (a programming book on designing and writing web applications using outrageously nerdy technologies – truly the “Great American Novel”), and found myself frequently needing a little pick-me-up that only mind-altering substances could provide. You wouldn’t think that writing a book would be all that hard – you either know a lot about something or learn about it, and then sit down and write about it in your chosen language (which I am currently pretending still qualifies as “English”). The material to be covered should be planned out well in advance and one can thus sit down and write, write, Write!

I never really intended for it to spiral out of control like that. I had just started writing my book (a programming book on designing and writing web applications using outrageously nerdy technologies – truly the “Great American Novel”), and found myself frequently needing a little pick-me-up that only mind-altering substances could provide. You wouldn’t think that writing a book would be all that hard – you either know a lot about something or learn about it, and then sit down and write about it in your chosen language (which I am currently pretending still qualifies as “English”). The material to be covered should be planned out well in advance and one can thus sit down and write, write, Write!