Skip Navigation Links

Page One

Campus Computing News

Mindset 1946

New Computer Based Training Courses

Today's Cartoon

RSS Matters

SAS Corner

The Network Connection

Link of the Month

WWW@UNT.EDU

Short Courses

IRC News

Staff Activities

Subscribe to Benchmarks Online
    

WWW@UNT.EDU


The Elixir of Life,                             or is it Variable Poisoning?

By Shannon Eric Peevey, UNT Central Web Support

Instead of focusing on ColdFusion this month, as I have done in the past, I thought that it would be fun to delve into the “other” language that I support on web2.unt.edu. That language PHP, which stands for “PHP: Hypertext Processor”, is a popular open-source scripting language that is used by many developers around the world. (See the list in “For More Information” for sites that are using PHP.) This scripting language has been a wonderful addition to our dynamic web server, and many of you are taking advantage of its ease and power.

PHP, Here We Go...

To get started, I would like to mention some of the great applications that have been written in PHP.

The first is our very own EagleMail application. This application is a variation on the IMP Webmail Client, which is available at the URL below, and which has been modified to become a great addition to the University of North Texas student communication system. This application allows students and staff to login to check there e-mail from any browser in the world. The stability of the application is seen as thousands of students check and respond to e-mail daily through this interface.

The second example, is an application that many of the web developers on my server are familiar with. This is PHPMyAdmin. This application is a web-based front-end for a MySQL database server, which is housed on one of my servers, and allows a user with the correct rights to administer their database from any browser in the world. As I have been supporting databases in a production environment for over 3 years now, I feel that I am fairly comfortable with a variety of database server/client interfaces. PHPMyAdmin takes the cake. It is not only easy to use, but it locks users down to the appropriate level of security, and allows me, the superuser, to administer everything from this single interface. (It has even replaced Microsoft Enterprise Manager for my favorite database administration tool. More information and a download can be found at the URL below.

The final application that I would like to mention is a shopping cart called osCommerce. This application not only has a complete user shopping cart on the front-end, but it incorporates a wonderful administrative interface as well. With the ability to include/exclude payment types, modify/add categories, monitor orders, osCommerce is a complete e-business solution for any company.

And Now for the Fun...

To initiate the newcomers to PHP, and to bring the old timers up-to-date, I feel that I should cover a basic issue that will need to be addressed in all PHP applications in the future. This is the creating and accessing of variables using PHP.

In the past, PHP3 and earlier, web developers were able to pass variables from page to page with ease. For example:

<FORM ACTION="firstApp2.php" METHOD="post">

<P><FONT SIZE=3><B> Please enter your name here:

<INPUT TYPE=TEXT NAME="NAME" SIZE=25></B></FONT></P>

<P><FONT SIZE=3><B> Please enter your telephone here:

<INPUT TYPE=TEXT NAME="TELEPHONE" SIZE=25></B></FONT></P>

</FORM>

Would place the variables NAME and TELEPHONE in memory to be accessed from “firstApp2.php”. To access these variables from “firstApp2.php”, you would write the following code:

<p align="left">__________________________________________________________________</p>

<p align="left">name: </p><H2> <? print "$NAME\n"; ?> </H2>

<p align="left">telephone: </p><H2> <? print "$TELEPHONE\n"; ?> </H2>

<p align="left">__________________________________________________________________</p>

First, notice the syntax. Is it hard to see? A little, because there is not much difference between the HTML and PHP coding style. (Even more, or less, confusing for those of you that have done some ASP coding, or a little JavaScript.) PHP was designed in this way. The creators wanted to make it easier for someone that has coded in some of these other scripting languages to be able to write PHP code with minimal difficulty. (They also wanted to pull some users away from the behemoth Microsoft too! ;) ) Here is a breakdown of what you see.

<? ?> -- These signify that the code found in between these symbols are PHP. The web server sees this, and send the code to the PHP engine, which then returns the code to the web server and then the browser.

Print – a function that prints text to a specified location.

$NAME – a variable name. A variable is signified by placing a “$” in front of the name of the form object on the originating page.

\n – a new-line character. (Acts like a carriage return.)

; -- line termination character. This is VERY IMPORTANT, as the omission of this character will cause problems when the code is compiled.

“string\n” -- the quotes designate a string, and the PHP engine will generate the code as such.

As some may notice, the syntax is very close to that of Perl, another favorite open-source language. This is also on purpose. It seems to me that web developers that have done some programming in the past are drawn to PHP, because of the ease with which they may transfer code and concepts from their previous languages. (In my experience, this tends to make for a more complete and stable range of available applications. Check out HotScripts.com for a wide range of available PHP applications.)

As you can see, this is very simple, and as with all simple things, there are some problems that have become apparent to PHP developers through the maturation of the product. This is that there is no scope designation for the variables that were created. This was by design originally. The PHP engine was supposed to guess the scope of the variable, and guess it correctly. As you all know, there are those people that like to find ways of working around things to their advantages, so PHP has had to come up with a different way of specifying the scope of variables, and in particular, global variables. (Scope is the realm within which a variable name's value can be accessed. See the URL below for more information about scope.)

Recommendations from PHP...

To help keep an end-user from “poisoning” the variables in your application, PHP implemented “predefined variables” to help specify the scope of a variable. Here is the example above, with the recommended syntax from PHP.

<FORM ACTION="firstApp2.php" METHOD="post">

<P><FONT SIZE=3><B> Please enter your name here:

<INPUT TYPE=TEXT NAME="NAME" SIZE=25></B></FONT></P>

<P><FONT SIZE=3><B> Please enter your telephone here:

<INPUT TYPE=TEXT NAME="TELEPHONE" SIZE=25></B></FONT></P>

</FORM>

The first page would remain the same. You will notice the modified code in the second page though.

<p align="left">__________________________________________________________________</p>

<p align="left">name: </p><H2> <? print "$_POST['NAME']\n"; ?> </H2>

<p align="left">telephone: </p><H2> <? print "_POST['$TELEPHONE']\n"; ?> </H2>

<p align="left">__________________________________________________________________</p>

 

Or in its simplest form:

 

<? print "$_POST['NAME']\n"; ?>

 

As you can see, the code is not that complicated, but does force you to understand the process of accessing variables. If you notice, in the <FORM> tag on firstApp.php, you see that the METHOD that we have specified is “post”. That means that we are moving the variable to an address in memory, instead of in the URL, as a “get” method would do. Therefore, we choose “$_POST” from our list of “predefined variables”. This “predefined variable” knows that it needs to look in memory for the value found in the array of posted form object values. Hence, the syntax of “$_POST['$variable_name']”. It is actually pulling the value from the “superglobal_arrays”.

Why am I telling you this?

As many of you know, we have had some issues with our local installation of PHP ignoring the register_globals switch, which mimicked a safe_mode=on type installation. This caused some PHP applications to fail over about a two day period, until I worked my “can of the Fonz” on it, and got it to work. What many of you don't know, is that PHP has been recommending the syntax of the second example above for over a year now, and is deprecating the syntax of the first example. (Meaning that it will not be supported by PHP at some point in the future.) Therefore, to be safe, in the sense of prolonging the life of your PHP applications and in the sense of making it more difficult for end-users to poison the variables in your application, it would be advised that you begin to update your applications to reflect the accepted syntax of the PHP creators, and the advise of web developers around the world.

Have a good one :)

For More Information...