Useful information for new PHP hackers

 
Post new topic   This topic is locked: you cannot edit posts or make replies.    34SP.com Forum Index // Scripting Support
View previous topic :: View next topic  
Author Message
theging
Super Member
Super Member


Joined: 27 Aug 2001
Posts: 636
Location: The square of the magnitude of my wavefunction is greatest around London and Manchester.

PostPosted: Thu Nov 25, 2004 10:11 pm    Post subject: Useful information for new PHP hackers Reply with quote
Guide to starting to write PHP by Daniel Martin, November 2004.

Hello all. My name is Daniel Martin, I've been hacking in PHP for a while now and I like to think I've gotten pretty good at it. I've taught myself from web tutorials, looking at other people's code, and of course experimenting! I've also learnt from numerous people on IRC that I've met who have been kind enough to help me out. I have some advice and knowledge that I'd like to impart on anyone just beginning to write PHP code (some of it might even be of use to intermediate hackers too!).

This text is mainly aimed at people who have never programmed before but some parts should even be useful to C / C++ gurus! It's also aimed at mainly at those using PHP for web purposes and assumes that you will be using PHP in conjunction with the Apache web-server and the MySQL database server.

Newbies should try not to be too overwhelmed by the sheer amount of information here. Some of it might not make sense on first reading you might need to experiment first before you see what I mean. Suggestions on improving this text are welcomed.

So here it is in no particular order:

1. Check your sources: Make sure any tutorials or books you use to learn from are up-to-date. PHP has been through some major changes recently and you don't want to be learning depreciated practices ie. Relying on register_globals.

2. Experiment on your own computer: Try and get Apache, PHP & MySQL installed on your home PC. As this will speed up development and will increase your understanding. Note, it certainly isn't necessary though as you can just upload every time you make a change to a script. - Bit of a pain though!
I would suggest people install a free unix-like operating system such as a GNU derivative (you can dual-boot and keep windows). Debian and Fedora Core are reputable GNU/Linux distributions. These to my knowledge come with Apache, PHP & MySQL pre-installed. They will also help you understand how the operating system that 34SP runs works. - Especially concepts like ownership and permissions (chmod). However all 3 pieces of software are available for windows as well. Worth noting at this point that Apache, PHP and MySQL are all free software.

3. Arm yourself with good tools: The better (and more comfortable you are with) the software you use to develop your PHP scripts the easier your life will be, so here are my recommendations:

a) Editor: Get yourself a nice text editor for hacking in. SciTE is nice and once again is free software. SciTE will handle many languages and will colour code them for you to make things easier to read and understand, it will also often make it clear when you've made a mistake. - Try missing a quote in PHP and you'll notice the difference.

b) Browser Use a decent browser when doing web development in general. Now that it's reached version 1.0 I recommend Mozilla Firefox over Mozilla. (Free software once again. - Detecting a pattern here?) Also be sure to grab the web developer plugin. As it performs many useful things. One being making it quick and easy to view the source of your pages. When coding in PHP this is useful.

4. Hack in `E_ALL': When developing in PHP you should have error reporting set to `E_ALL'. This can be done by editing your php.ini file. In a .htaccess. Or in your PHP code itself. For the latter option simply place `error_reporting(E_ALL);' immediately after your first PHP tag `<?php'. Note there are no quotes around `E_ALL' as it is a predefined constant. ie.
Code:
<?php
error_reporting(E_ALL);

This level of error reporting will pick up on even the smallest mistakes, and prevent you spending ages debugging an elusive problem. This may strike you as pedantic at first but once you become used to it your code will be of a higher standard, you'll understand PHP better and you won't have to worry about nasty, hard-to-see bugs in your code (such as when you've forgotten to set a variable).

5. Batten down the hatches: Configure your environment to be strict and secure. Eradicate as much silliness as you can from PHP. There have been a few features in PHP that have either made the language non-intuitive or caused security problems etc... but have had rather noble roots. Often based on making novice programmers code secure or making the language easier to pick up. However experience has shown that it's best to turn these off. There are a few, (please tell me if you think I've missed any!):

a) register_globals: This needs to be turned off. Just to explain I'd like to give an example demonstrating how register globals works and how it can be insecure.

Let's say you have a script called square.php on your web-server you want a variable `$foo' to be supplied by the user via a POST form:

Code:
<?php

if(!empty($foo))
{
   $bar = $foo * $foo; // $bar is $foo^2
}
else
{
   $bar = 0;
}

echo $bar;

?>


If register_globals is on this will work. For example if the user enters 3 in the form field named `foo' then the script will echo 9 back to him. However there is ambiguity in where the $foo variable has come from. There are three possibilities, a cookie variable, a post variable (as we anticipate) or a get variable (ie. in the query string). When we don't know where variable has come from this can cause problems. It would be possible to link to a specific output of the script even though you may not wish to allow this, ie. square?foo=3 may be linked to and will produce the output of 9.

Code:
<?php

if(!empty($_POST['foo']))
{
   $foo = $_POST['foo'];
   $bar = $foo * $foo;
}
else
{
   $bar = 0;
}

echo $bar;

?>


Is the way to do it without using register_globals. As you can see there is no longer any ambiguity in where our input variable (foo) has come from. So far it just looks like register_globals just leads to confusion in one's code but it actually creates security problems in badly written code.

Code:
<?php

/*
 * This file has been included from an earlier file.
 */

if(login_user($username, $password))
{
   /*
    * The login was successful! Let's set the user's
    * status to `logged in'.
    */
   $logged_in = 1;
}

if($logged_in == 1)
{
   /*
    * We believe the user to be logged in and trusted
    * so let's offer him the site administration area.
    */
   admin_area();
}

?>


At first glance this code looks reasonable if amateurish. However if we consider the case of this code running with register_globals on, what would happen if someone was to request the page with `?logged_in=1' in the query string? The user could access the administration without needing either a username or password! If memory serves a very popular web portal had a flaw just like this in it. It's worrying that so many popular web portals and other large web software still require register_globals to be on in order to work.

In summary register_globals is nice for novices but doesn't promote understanding and worse creates huge security holes. (Not so bad if your code never produces any notices under E_ALL but turn it off none-the-less.) register_globals now defaults to off for this reason. However because many popular scripts still depend on register_globals many hosts have it set to on (34SP included I believe at the time of writing). You should use a .htaccess file to turn them off.

To turn off register_globals you'll need a .htaccess file (note the `.' it's important!) with the following line in it:
Code:
php_value register_globals 0


b) magic_quotes This was created to prevent SQL injections. It performs it's job well but can lead to confusion in other areas and insecurity if your code is ever run with magic_quotes turned off. It's best to turn it off (.htaccess again or php.ini) and perform add_slashes() on every variable that goes into a SQL statement. This will prevent SQL injections. But don't take my word for it, do some research into SQL injection attacks and see for yourself!

To turn off magic_quotes you'll need a .htaccess file with the following lines in it:
Code:
php_value magic_quotes_gpc 0
php_value magic_quotes_runtime 0


6. Tidy Code: You should keep your code clean with a consistent style if you can. Your style will change with time so consistency isn't too important however you should be sure to indent where appropriate. ie. anything between { }. Also be sure to comment your code. Novices always underestimate the use of commenting. Comment to explain what a file does, how a function works, and what a large conditional statement does. You will confuse yourself less this way.

The issue of coding style is a controversial one, find what works best for you. Try not to become too indoctrinated by the first tutorial you come across. For example I would indent with tab spaces and put every curly bracket on it's own line (I find this creates a symmetry that helps me to understand code when I look back on it). For example here is the `joke code' in my current signature written out in my normal style:

Code:
<?php

/*
 * This file just decides what to do next depending on
 * whether the user is using an ethical operating
 * system.
 *
 * Note: $System is an object that's already been
 * defined in an earlier file.
 */

function do_stuff($os, &$System)
{
   if($os == 'GNU')
   {
      echo 'Yay for freedom!';
      $System->Sing('GNUFreedomSong');
   }
   elseif($os == 'Windows')
   {
      echo 'Why postpone the inevitable?';
      $System->Crash();
   }
   else
   {
      echo 'Ooh exotic operating system (or maybe BSD)!';
      die('Don't know what to do! :-(');
   }
}

do_stuff($System->Crash, $System);

?>

Please note that there will be many people who hate my style - mainly people who like K&R :-S. This topic is known to cause holy wars so I won't delve any further into it and certainly won't declare one style superior over all others.
By the way K&R style is much like this:
Code:
<?php

function foobar($foo, $bar) {
   if($foo == $bar) {
      stuff();
   } else {
      other_stuff();
   }
}
?>

If you want more information on coding style then google is your friend. As I say be careful when discussing it as it's a holy war inducing subject!

Well that's all I think. I hope that this text has been helpful and informative. If there's anything that requires further explanation or illustration then please ask. If anyone has any corrections then let me know also if you think I've been rude or patronising anywhere let me know as this sometimes happens by accident - it's hard to explain yourself with just text, much emotion is lost.

Special thanks to Miguel (SfCommand) and Colin (csogilvie) for reading though this and offering suggestions.

Please post any comments, suggestions and/or questions you have below.
_________________
All the best,


Daniel.

PS: Follow my links and read! :: Why am I mad at you? - I'm not, this is just my way of expressing interest in your opinion!
Code:
if($os == 'Windows'){ echo 'Why postpone the inevitable?'; $System->Crash(); }
Back to top
View user's profile Send private message
Post new topic   This topic is locked: you cannot edit posts or make replies.    34SP.com Forum Index // Scripting Support All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Powered by phpBB © 2001, 2002 phpBB Group