This is not PHP.net, this is http://takien.com/

takien.com is NOT php.net

This is not Takien.com, this is PHP.net

This is not taiken.com, this is php.net

• Windows: 42%
• Linux: 38.5%
• Mac OS X: 19.1%
• Everybody else: 0.4%

The Register is only telling half the story. 38.5% on Linux is a fantastic percentage. I for one am a happy Ubuntu & Gnome desktop user and I haven’t depended on Windows desktop for at least 6 years. Its a shame though that so many employers and technical people still use Windows desktop when Linux Desktop has everything you need, its free, and its not crap either. Funny that the circling vultures at The Register would focus so much on how PHP coders are still on Windows, and fail to point out that as a group they are agressive adopters of Linux Desktop. Visitor stats for websites indicate that Linux desktop is a lot less than 38.5%.  PHP developers are helping lead the way for Linux as a choice for the desktop that is fast encroaching on Windows turf. That turf will soon be taken away from Windows by Linux. Somebody should have pointed that out. Guess that is what I am doing.

Linux dominates the web server world, and it makes darn good sense to see run the same system on the desktop as for the server for reasons of uniformity and behaviour. Its an obvious right choice to make. Learn to work well in the Linux shell on the desktop and you can use all those skills on the server.

Oddly, The Register reported all this but did not supply a reference to the source report on Zend.com

Source: http://www.theregister.co.uk/2010/02/17/php_windows_linux/

Relative Cost Of A Software Bug Fix

Slide credit: Barry Boehm, “Equity Keynote Address” March 19, 2007.

This chart is intended for developers, to decide how best to spend ones time. Ever wonder why, as a developer, fixing bugs is such a pain and a kludge? There is something not simply tough about fixing bugs, there is something fundamentally wrong about putting any effort at all into repairing them. But the chart is also a message to the paying client, the person whose dime it is on. A client may be only thinking in the short term to make the software work, but it is the most expensive and unproductive path to the realization of goals.

The effort to fix bugs is great and the rewards are minimal. Frustrations are high, satisfactions are low. The website suffers from some sort of performance penalty, users are inconvenienced. Bugs must be dealt with with some amount of procedural overhead no matter what, and when the bug is fixed and submitted, very little was ever really accomplished. It is really far better to think of a better solution to all your problems together rather than to continue fixing things one at at time. It will cost the customer less and they will get more. So when bugs become a staple of the work load, its time to persuade the client to accept a rewrite.

…with the software in production, fixing bugs is akin to repairing a car while it is driving down the road, long after it has left the drawing board, the assembly line, and the dealer lot. Its as expensive to do as it can possibly be.

Developers still have a great deal in common with the clients they perform work for. They charge money for their work so they think in terms of the cost in terms of labor time (actually, developers also think this way when they work on their own software). The question every developer asks is, “What is the simplest, easiest, and fastest way to get something done?” The answer could be open to interpretation, but that is because the long view must be taken into consideration, and that is why software makes use of functions, templates, classes, objects, and design patterns. The work is needed now, but how will it be possible to understand the software in a few months time when noone is mentally fresh? How do I share my ideas with other people? How do I take the long view into account?

Despite the love a client may have for their own project, nobody is interested in working on the same software forever. After all, software developers are creative people who really want to expand their skills and take all that they have learned and apply it to the next project, instead of keeping something half dead on life support.

I enjoy attending talks from the best people in the world in my business, because they are very good at exposing the importance of planning and organizing the overall picture, and are very knowledgeable in all the concepts that make projects produce a top quality result in an efficient manner. They also point out the simple mistakes people make that cost them so much. When we are at the far right of the graph, with the software in production, fixing bugs is akin to repairing a car while it is driving down the road, long after it has left the drawing board, the assembly line, and the dealer lot. Its as expensive to do as it can possibly be.

Developers should try to understand the message of this graphic before going further fixing bugs. If you are put in a position fixing bugs, it is time to change the way you work, because you are the one bearing the cost in terms of your own time performing the least valuable, most expensive, and least meaningful work.

Web developers as they learn start by downloading packages in zip and tar.gz archives which is fine. A pro technique is to pull in the resource via SubVersion (svn). Svn provides additional features such as svn externals and svn hooks. Svn externals allows for the pulling in of external resources into a defined project in a svn repository. Svn hooks is for additional labor saving scripting that allows for the automation of repeated tasks such as a script that can pass along data from commit messages into other resources in the project such as the bug tracker. Learning these tricks allows for labor savings at every step in the production cycle. We can take these practices to the next level with capturing the commands in a bash script and then organise all the features of a website in a deployment script, something that is done all the time at software majors.

This script is a big-ass time saver.

I took the time to sort this out recently because I had some web development requests from people who have simple websites that could be converted to WordPress easily enough, but I wasn’t interested in going fishing for plugins and themes twice, and again when the next people come along needing the same thing. The job of a software developer should be to automate processes. I say often that the credo of developers is not to work for a living, but to eliminate work. But this idea is not always employed by developers in all the places it could, and its sometimes even a harder to get a client on board to make full use of methods and procedures that automate tasks and eliminate work.

…the credo of (software) developers is not to work for a living, but to eliminate work.

Lets at least cover the benefits in point form:

• The script takes a couple of minutes and you save hours.
• You dont repeat the labor, but you can repeat the use of the script, deploying anywhere else.
• All your stuff is there at the beginning. Useful for planning, development, and policy across teams.
• You are organised, and you can develop variations. Svn export may be good enough for your needs.

In pseudo code, here is what your script will do:

• Set up your repository.
• Make your directory structure for your project.
• Check out your repository.
• Run procedures for svn externals for core WordPress.
• Run procedures for svn externals for plugins, iterating through data in an external file resource.
• Run procedures for svn externals for themes, iterating through data in an external file resource.
• Grab additional resources in an array, iterate through them using wget command, extract them.
• Cleanup.
• Commit message.
• … anything else you can think to do.

The bash file, save as getallwpsvn.sh:

#!/bin/bash
# run this script with chmod 755 permissions.

workPath=$(pwd)

rm -rf filerepository repository www *.zip # this line cleans dir for testing, comment out when done

svnadmin create repository

mkdir -p filerepository/{branches,tags,trunk/{html,db,cron,scripts,themes,plugins,project,selenium}}
# got anything to import into those directories under trunk?
# import into the directories under trunk now
# before the next step
svn import filerepository file://$workPath/repository -m "initial import using getallwpsvn.sh script"
rm -rf filerepository
svn checkout file://$workPath/repository/trunk www
cd www
svn rm html
svn commit -m "rm html temporarily for clean propset"
svn propset svn:externals 'html http://core.svn.wordpress.org/trunk/' .
svn up
cd html/wp-content/
# get plugins from repository http://svn.wp-plugins.org/
# plugins listed in svn.plugins.externals
svn propset svn:externals -F ../../../svn.plugins.externals plugins/
#svn commit "plugins propset" # no commit if no local repository
svn up
# themes repository: http://svn.wp-themes.org/
# themes repository is a bit of a ghost town, none grabbed here
# browse the site and get the zip
# themes listed in svn.themes.externals file, if there are any
svn propset svn:externals -F svn.themes.externals plugins/
svn up

cd themes
# load up on themes
#more human readable format for array

THEMESITES[0]=http://dev.digitalnature.ro/fusion/fusion-wordpress.zip
THEMESITES[1]=http://ericulous.com/?load=googlechrome.zip
THEMESITES[2]=http://ericulous.com/?load=internetcenter.zip
THEMESITES[3]=http://ericulous.com/?load=redbusiness.zip
THEMESITES[4]=http://wordpress.org/extend/themes/download/elegant-box.4.1.1.zip
THEMESITES[5]=http://wordpress.org/extend/themes/download/thirtyseventyeight.4.0.zip
THEMESITES[6]=http://wordpress.org/extend/themes/download/thirtyseventyeight.4.0.zip
THEMESITES[7]=http://wordpress.org/extend/themes/download/constructor.0.6.4.zip
THEMESITES[8]=http://wordpress.org/extend/themes/download/jq.2.4.zip
THEMESITES[9]=http://wordpress.org/extend/themes/download/ahimsa.3.0.zip
THEMESITES[10]=http://wordpress.org/extend/themes/download/retromania.1.3.zip
THEMESITES[11]=http://wordpress.org/extend/themes/download/skinbu.1.0.3.zip
THEMESITES[12]=http://wordpress.org/extend/themes/download/mystique.1.16.zip
THEMESITES[13]=http://wordpress.org/extend/themes/download/lightword.1.9.3.zip
THEMESITES[14]=http://wordpress.org/extend/themes/download/monochrome.2.3.zip
THEMESITES[15]=http://wordpress.org/extend/themes/download/thematic.0.9.5.1.zip
THEMESITES[16]=http://wordpress.org/extend/themes/download/hybrid.0.6.1.zip
THEMESITES[17]=http://wordpress.org/extend/themes/download/new-york.1.0.1.zip
THEMESITES[18]=http://wordpress.org/extend/themes/download/f8-lite.1.3.zip
THEMESITES[19]=http://wordpress.org/extend/themes/download/simplex.1.3.1.zip
THEMESITES[20]=http://wordpress.org/extend/themes/download/cleanr.0.1.2.zip

for s in ${THEMESITES[@]}
do wget "$s"
done

FILES="*.zip"
for f in "$FILES"
do unzip "$f"
done

rm *.zip
rm *.zip.*
cd ../../../
svn commit -m "load in of plugins and themes complete"

cd $workPath
cp $workPath/www/html/wp-config-sample.php  $workPath/www/html/wp-config.php
chmod 777 $workPath/www/html/wp-config.php
chmod 777 $workPath/www/html/wp-content #temporarily, for cache
mkdir $workPath/www/html/wp-content/uploads && chmod 777 $_
touch $workPath/www/html/.htaccess && chmod 777 $_

# do any post processing, other importing now, and commit it if you did.

Set the file permission to chmod 755, and run it from the shell command line as in ./getallwpsvn.sh.

The file you save as svn.plugins.externals:

all-in-one-seo-pack http://svn.wp-plugins.org/all-in-one-seo-pack/trunk
advertising-manager http://svn.wp-plugins.org/advertising-manager/trunk
cforms http://svn.wp-plugins.org/cforms/trunk
google-sitemap-generator http://svn.wp-plugins.org/google-sitemap-generator/trunk
sociable http://svn.wp-plugins.org/sociable/trunk
stats  http://svn.wp-plugins.org/stats/trunk
ultimate-google-analytics http://svn.wp-plugins.org/ultimate-google-analytics/trunk
vipers-video-quicktags http://svn.wp-plugins.org/vipers-video-quicktags/trunk
wordbook http://svn.wp-plugins.org/wordbook/trunk
wp-flickr http://svn.wp-plugins.org/wp-flickr/trunk
wp-super-cache http://svn.wp-plugins.org/wp-super-cache/trunk

The svn.plugins.externals file is a name – resource listing, one per line, when you have more than one resource to define with svn externals.

Please note that you may not need all of this; comment whatever out you want. You dont need to create a local repository, that is only if you are doing team development, or perhaps custom development on themes and plugins. I found though that it was necessary with svn propset directives to create a top-level directory structure wherein is stored all the different directories. The point of this exercise is a pull-in of public resources in a step that you can repeat automatically over and over. It also need not be a very sophisticated script to get the benefits from it.

I had of course heard of svn externals before but a little explanation really enlightened me. You can multiply your power as a developer with svn externals. Alongside your own project under svn control, you can add in other remote projects from remote svn repositories with the svn propset command and they will naturally remain current as you run updates on your own repository.

You can multiply your power as a developer with svn externals.

In the struggle for project housekeeping it can be a chore to keep libraries, plugins, middleware, and other goodies up to date. In general we as developers have a mindset about keeping a project managed by version control, but its an idea that I have seen stopping at the project in question. The project is under svn, the rest of the libraries are from static resources like tarballs. By just extending the power of version control just a little bit further, we have a big labor saver, and we are opened up to the great universe of software. Svn externals gives us mighty lever, because we then have the power to keep in step with all of the other bits and pieces that go along with a project.

Your main project is under version control, but your rich html editor, TinyMCE, is not. Well it can be. Lets use it as an example.

test$ mkdir tmc
test$ cd $_
test/tmc$ mkdir html
test/tmc$ mkdir project
test/tmc$ cd $_
test/tmc/project$ mkdir branches tags trunk
test/tmc/project$ cd -
/home/pbg/websites/test/tmc
test/tmc$ cd html/
test/tmc/html$ ls
test/tmc/html$ emacs index.php
test/tmc/html$ cd ../
test/tmc$ cp -rf html project/trunk/
test/tmc$ ls
html  project
test/tmc$ ls project/trunk/
html
test/tmc$ ls project/trunk/html/
index.php  tiny
test/tmc$ ls
html  project
test/tmc$ rm -rf html
test/tmc$ ls
project
test/tmc$ svnadmin create tmcrepository
test/tmc$ svn import project file:///home/pbg/websites/test/tmc/tmcrepository -m "initial import"
Adding         project/trunk
Adding         project/trunk/html
Adding         project/trunk/html/index.php
Adding         project/branches
Adding         project/tags
Committed revision 1.
test/tmc$ ls
project  tmcrepository
test/tmc$ svn checkout file:///home/pbg/websites/test/tmc/tmcrepository/trunk .
A    html
A    html/tiny
test/tmc$
/test/tmc/html$ svn propset svn:externals 'tinymce https://tinymce.svn.sourceforge.net/svnroot/tinymce/tinymce/trunk' .
/test/tmc/html$    svn commit -m "propset"
/test/tmc/html$    svn up
/test/tmc/html$

So that is how its done from bash with a vanilla website and one repository checked in for your pleasure. Tips to know include wrapping the directory and resource in quotes, don’t create the directory, specify it in propset and let svn create it for you. Go to a directory somewhere else on your system and test your checkout. In the example above the remote repository trunk is checked out. However, you are also able to check out specific branches or even specific revisions if you want the bias more to stability over new features. You can also specify multiple remote repositories by creating a text file with directory and remote resource pairs and point svn propset at that file. Be prepared to handle things that you flub up using svn propedit. Your repository is not broken, but you may have to know how to fix a thing or two that you didn’t do the first time. That is why doing a vanilla procedure like what is described above helps show what the right way is.

So Imagine having a repository somewhere with all the tools you like to work with as part of your own best practices, sitting there, in one place ready to go with one checkout. That whole kit and kaboodle becomes your blank slate from where to start from, but you are already miles ahead of the competition because you already have tabs on all the resources you are going to use in your project. Having it all on hand saves labor and helps foster better practices as a developer.

• Zend Framework, CakePHP, Symphony, PEAR or whatever middleware turns your crank
• PHP Unit, or SimpleUnit, or some other unit testing suite
• WordPress, Drupal, Joomla, or of course any of the related themes and plugins
• Tiny MCE
• Jquery, Scriptaculous, Dojo, whatever floats your boat with javascript
• XDebug,
• phpmyadmin
• Integration testing software like Selenium or Molybdenum
• bloody well anything from sourceForge, or anything else for that matter public and under svn control.

Links for this blog post:

http://www.superwebdeveloper.com/2008/10/08/essential-cheat-sheet-of-shell-commands/

http://devzone.zend.com/article/9930-The-ZendCon-Sessions-Episode-26-Best-Practices-of-PHP-Development

http://beerpla.net/2009/06/20/how-to-properly-set-svn-svnexternals-property-in-svn-command-line/

http://blogs.gnome.org/johannes/2008/02/20/svnexternals-for-noobs/

We had thousands of possible beers to choose from, but we were most attracted to the pumpkin beers from local microbreweries from the taps. We enjoyed a down home meal of mussels, beef, and a crab cake sandwich and fries. A few things to point out in the pics above: Not the skull foam in the beer glass, the chocolate cake, the double chocolate stout, the elephant tap, the cans in the wall, some familiar faces from the php community, and the trappist ale. So never mind the fine dining in DC, go for the soul food and beer.

The conference was great, I learned stuff, I learned what I know, what I dont know, what I need to know, and more. I met a great group of people and traded lots of business cards.

Drupal Community Support Is Now Upside Down

Drupal creator Dries Buytaert has made some copryright changes that are now pissing off the web community. The new trademark policy, indroduced at the end of August 2009, now forbids the registration of domains like drupalSucks.com, and any site using Drupal in the name now must fork over $$$$$. WTF? Its a baffling move from such a well known member of the community, who has prospered from the concept of free software, sharing and free expression.

…it is a pretty impressive piece of software. But people should be free to criticize it in any way they see fit, including the registration of domain names that are less than flattering. (source).

Unfortunately, these greedy assertions in a community that functions because of the freedom of expression, sharing and openness usually only serve to anger people so much as to go out and register domains like drupalSucks.com which they use to spread the word about what a stupid idea this is.

Fallout is starting already. Free Drupal Hosting which, like the name sounds, provides free hosting for drupal sites, may not be willing to do so in the future.

There are draconian restrictions on the use of the word ‘drupal’, which would require us to give up a good part of our income, the truth is that the income from the ads is so low that we barely make enough to pay for hosting and bandwidth. We would not mind that but we refuse to make a loss on this service because of a silly trademark, with restrictions that – if they weren’t so sad – border on the hilarious. (source).

Creating a domain name that uses a preexisting name in the case of drupalSucks.org is covered under ‘Nominative Use‘, as an affirmative defense to trademark infringement. The Drupal community will be set to scream long and loud over this. And companies who market their services using Drupal, making sites with Drupal, and companies that write code in the Drupal framework are bound to think twice about whether they want to use it due to these new restrictions.

Here is an example of something I saw recently. Names have been changed to protect the innocent.

<?php
foreach ($fieldName as $field=>$type) {
$UserObject->setValueInDB($field, $$field);
}
?>

This is from a form submission script. There are a couple of transgressions I can think of, not least of all the reliance on the register_globals directive which is now off by default, and soon to be eliminated from a future release of PHP.

The variable variable part here is $$field, basically, what has been posted. The $fieldName value is a list of fields grabbed from the table, so you don’t trust $_POST. But what is the point in trusting the scalar equivalent of your posted value? You are getting farther away from certainty, not closer. A $_POST submission from an attacker could wipe out data because their $_POST array doesn’t have any keys that your table has. As well, if your $_POST array on your own page doesn’t have a $key=>$value that is also in $field=>type, well that value is going to get wiped out. In the case of a user profile edit page, a form page probably wont have all the fields that are posted. Especially if a developer doesn’t consider using table joins elsewhere.

One of the cardinal rules of programming is never trust user input. And I consider losing user data to be a deadly sin. But setting up a situation where you risk losing data in a field because of one additional field in the table for the user is downright dangerous.

One of the early-ish contributors to PHP, by virtue of being a C programmer, was no doubt familiar with the variable variable language construct, and appreciated its eloquence in CRUD scripts and elsewhere. You got your field names, so cycle through them in a looping construct and execute your value setting method.  He or she is forgiven for not realizing that eventually, with the blossoming of a thousand new web hosts and thousands more developers on the web, not only users had to be protected from themselves, but developers from themselves also. And so, as of release 4.2.0, register_globals was finally set to OFF by default. Many hosting companies have been slow to react, and even today set it to ON to support legacy software.

So while you have this spartan and eloquent structure, it relies on an obtuse language construct which in turn relies on data that is potentially not trustable. The solution to the above problem required a static array of field names that must not be overwritten. Of course, testing this once might reveal that data is being overwritten with empty values. Unintentionally. By design. Due to a deprecated directive and an obscure language construct.

function printR($arr, $label= null) {
if($label){
echo “<h2>$label</h2> \n “;
}
echo “\n\n<pre>\n”;
print_r($arr);
echo “\n</pre>\n\n”;
}

You can of course do fancier things should you wish to dump your results to a directory before overwriting your files.

#!/bin/sh
for files in `find *.php`
do
sed ‘s/..\/..\/adminincl/includes/g’ $files > ‘temp’.$files && mv ‘temp’.$files $files
done

It would work like this:

• set a number of allowed login attempts.
• set the time limit in seconds for duration of access denial.
• keep track of the number of failed login attempts.
• keep track of when login attempts started with timestamp function.
• test for meeting or exceeding the number of allowed login attempts.
• let them keep trying if they have waited past the time limit.
• set a time limit for when they can come back, and forbid them.
• give them some messages and links to help.
• if the login has been successful, wipe out all the tracking for login attempts.
• You are done.

Here we go, into your login processor after initial validation and constructing a sql query.

$loginAttemptsAllowed = 5;

if( $_SESSION['loginAttempt']['Count'] <= $loginAttemptsAllowed ) {
  $result = $db->queryRow($sql); // only query db if allowed to do so
}

if( !$result ){
  $seconds = 300; // 5 minutes
  // if trying again after lockout time limit ....
  if( $_SESSION['loginAttempt']['Count'] >= $loginAttemptsAllowed ) {
    $difference  = abs($_SESSION['loginAttempt']['LockoutTime'] - $_SESSION['loginAttempt']['Time']);
    $diffSeconds = round($difference);
    if( $diffSeconds > $seconds ) {
      unset($_SESSION['loginAttempt']); // they failed but have a new set of chances
      } else {
      $minutes = $seconds / 60;
      $message = "Sorry, you have had $loginAttemptsAllowed failed login attempts. <br />
      We temporarily forbid access in order to protect your private information. <br />
      Please wait $minutes minutes before logging on again.";
      }
    } else {
    if( !isset($_SESSION['loginAttempt']['Time']) ) {
      $_SESSION['loginAttempt']['Time']  = get_microtime();
      $_SESSION['loginAttempt']['Count'] = 1;
    } else {
      $_SESSION['loginAttempt']['Count']++;
    }
    if( $_SESSION['loginAttempt']['Count'] >= $loginAttemptsAllowed ) {
      $_SESSION['loginAttempt']['LockoutTime'] = get_microtime();
    }
    $message = "login error";
  }
  addMessage($message, "MsgErr");
  redirect($_SESSION["backPage"]);
  exit();
}

….. go on and log them. Dont forget to unset( $_SESSION['loginAttempt'] );
// a couple of the functions in there are custom ones, they are basically just wrappers.
// I forget where I got the following function, but it is used for benchmarking. Maybe php.net?

function get_microtime() {

  $mtime = microtime();

  $mtime = explode(" ",$mtime);

  $mtime = doubleval($mtime[1]) + doubleval($mtime[0]);

  return ($mtime);
}

So there you have it. Forcing users to have highly secure passwords, while a good idea, is not always possible.

Keep your users safe. And curses to wordpress for screwing up my code formatting…

Create a moving target that attackers cannot seize upon repeatedly. build arrays in a looping construct for all the form fields you want to assign in your page. Store them in a PHP Session array. You use built-in php functions such as md5(), uniqid(), microtime(), mt_rand(), and a salt value if you like as well. You output your form fields dynamically, using php to assign the randomized hash to the name value of the form field. Enter some data, submit the form. The script takes your $_POST array and compares the array keys to $_SESSION. You can then do further validation and then assign your values to common sense variable names that are always private.

When you have validated this submission, you know the data has come from your form page. While you can spoof referrers, You cant spoof the form field names because they are only created at runtime.

The honeypot is the inverse approach, And also has lots of fans in its camp. A honeypot is a web form with addtional form elements, usually of a hidden type, that get discovered by a spammers crawler. They then seize upon the field name and use it in an attack. But since the form field isnt visible to users through the browser, it must be some kind of forged submission, and is worthy of filtering out.

The advantage of the moving target over honeypot is that forged submissions can be filtered out earlier in the script. Also, an attacker could easily analyze the form page once and determine what form fields to omit, and just add that information into the submitting script. They visited the page once, made a correction, and are back in business. Even so it is known as a successful defense. It is a successful defense because of the reason spam is spam: people messing with your site without ever even visiting it, not once. And if you are using an off-the-shelf website-in-a-box like WordPress or Drupal or whatever, the attacker can even more easily attack your site, with its cookie cutter template form elements, one same as the other million out there already.

It is very economical to attack as many sites as possible in the same way as possible. It will always be so.

I have had my share of naysayers over the moving target method. Please allow me reply to a few of the comments others have already made.

Why not just use the form name, why all form fields? I guess you could, but really there are a couple answers. First is the concept of defense in depth. Secure the whole thing, not just one element that an attacker could lock on to. Next answer is that it is simple enough to do the work in php to generate all the form field names you wish.

The site could still be attacked. Yes. Assume that it will be. Funky forms is of course not the only line of defense you must apply to stop your site from being trashed. What I was able to accomplish here is to break the link between the site and the garden variety automated attack, which must assume to know your form name and names of input fields in order to forge the rest of the information. The client must be on your web page in real time to submit data into your form. And in fact that is all the moving target approach does. The attacker still harvests your page, prepares a http remote attack in the guise of a simulated form posting, then goes to work, submitting to all the websites. But nothing gets through to a site with the moving target approach because field names wont match up.

A position based attacker could still hit it. Yes but of course you are not done validating your input because you have this in place. Spam, like anything else, is a matter of economics, in terms of both time and money. Yes someone could get you, but not likely, because like 2 boxers in a ring, both have to be stationary for a moment for a punch to connect. Otherwise its much harder to be effective, and much less powerful. The analogy is a fair one: The time required to hit a site with moving target is greater than the time to perform the usual kind of automated crawling and submitting designed for static form field names. The mere fact that you require your user to be on your page, absolutely, is enough in itself for attackers not to bother changing its tactics for millions of websites, or to lose so much time to making an exception to you that it becomes uneconomical to do so. As it stands, they may never even know that their submission was unsuccessful. You can of course push suspicious submissions to Akismet.

Yeah but sessions are evil and should never be used. Some have said so. Not to long ago, they didn’t work very well. But this isnt the case anymore. Drupal doesn’t use sessions, for example, and other middlewares avoid them as well. Projects with requirements for handling legacy code, particular kinds of services or policies may insist that sessions not be used. But even more evil is to never use sessions because of not understanding how to use them properly and parsimoniously.

First comes your form page, use some php before the form to generate the fields that you need.

<?php
session_start();
if(!$_SESSION["subscriber"]["values"]) {
  $fieldNamesCount = 11;
  $fieldNamesArray = array();
  for ($i = 0; $i < $fieldNamesCount; $i++) {
    // $fieldNamesArray2[] =  md5("killSpam" . uniqid(microtime(), 1)); // random coctail with salt, if you wish
    $fieldNamesArray[] =  uniqid(md5(mt_rand())); // random coctail
  }
  $_SESSION["subscriber"]["fieldNames"] = $fieldNamesArray;
} else {
// do something when its a return pag
}

echo "<pre>";
print_r($fieldNamesArray)
echo "</pre>";

……. and then your form fields look something like this:

Name: <input type="text" name="{$_SESSION["subscriber"]["fieldNames"][0]}" value="<?php  echo  $_SESSION["subscriber"]["values"][0]; ?>" size="20" maxlength="50" />

Phone: <input name="{$_SESSION["subscriber"]["fieldNames"][1]}" type="text" value="<?php echo  $_SESSION["subscriber"]["values"][1]; ?>" size="20" maxlength="20" />

You submit this to your form target script. If you look at your page Info in Firefox, under the forms tab, you will see you have form field names created from random hashes generated at runtime. The values for the names will be unique at every page load. The user must be on the page to submit.

So lets take a look at the script you are posting this data to.

Lets just assume that you are pointing this form submission to a different file, so here is what is required at a minimum:

<?php
session_start();
if (!$_POST) {
  echo "no post reference";
  exit();
}
// compare $_SESSION["subscriber"]["fieldNames"]
// to array_keys($_POST);
if(!$_SESSION["subscriber"]["fieldNames"]) {
  echo "no ref to my session";
  exit();
}

$postedKeys = array_keys($_POST); // I need to access this as an  array.

$_SESSION["subscriber"]["values"] = $_POST;
$realNames = array('Name','Telephone',.... etc);

for($i = 0; $i < count($postedKeys); $i++) {
  if($postedKeys[$i] == $_SESSION["subscriber"]["fieldNames"][$i]) {
    // no cheating! you must you my randomly generated field names to use this page!!!!
    $realValues[$realNames[$i]] = $_SESSION["subscriber"]["values"][$_SESSION["subscriber"]["fieldNames"][$i]];
  } else {
    // its the work of satan
    echo "please dont do that ";
    exit();
  }
}

so if it passes all the tests, its good to go. Otherwise, its like two people talking to each other who dont speak each others language. They will never get what each other is saying, will never understand, and will just move on.

But really, this is a problem that is endemic to cms packages. A hacker can write one script and attack all drupal sites on the world wide web. Same problem for wordpress and every other website in a box. They all have a url that someone can post to with name & value pairs. There are always lots of things to do to protect your site, but with every new upgrade and patch, there are always new exploits that might just work when applied to your site.

Without a human being to look and see, you wont know that your site has been tossed until you see it for yourself, and remains that way until it is fixed.

Randomizing not only the form name but also the field names was a very successful experiment in my case when someone had my number. The attacker cant presume the name of your fields then so easily, and then they cant attack you. Its like you become a moving target, not a static one. At the very least, they actually need to be on the page in real time in order to post something. Now other developers have told me that in fact it could be attacked with a position based form filler, say based on a xul widget or hacked firefox, but this solution, while possible by some attackers, is generally extra effort to include in the whole looping construct for the attack.

Spam networks hire out at at least $5000 an hour, I learned at a VanLug talk last year. So if an exploit takes too long to seize on to, it is not worth the time. CMS packages are uniform instances of software in terms of action urls and form and field names, so they are static things to sieze upon in the eyes of an attacker who has to provide the biggest bang for the buck. They are sitting ducks, just waiting to get attacked. If even an array key was constructed of a md5 hash at page load time, stored in a session  (oops, no sessions in Drupal, not Kosher, if you are a Drupalist), that at a minimum would be enough to be a moving target an attacker would be unable to sieze upon without actually being on the page in real time. And that is the whole problem with spammers, they never even visit your site. Never have and never will.

Some of you may have been wondering, why is a PHP group doing an event like OpenWebVancouver 2008. The reason is that we have held very successful conferences in the past and we would like to do more. As a volunteer run, community based group, we are a group of dedicated people who would like to bring in new people into our community who share our common interest in Free Open Source Software.

PHP Developers always have to be aware of so much more than just PHP. We have to be well acquainted with the whole LAMP stack and much more. This is also the case with our colleagues who code in Python or Ruby on Rails or who are designers – they have to know much more than what their discipline represents. And hosting an event that would focus only on PHP while interesting to us, would not serve the purposed of exposing ourselves to new information.

It is time we felt, for people in the different areas of Open Source to come together and be more aware of each other. Vancouver has over 20 user groups for different technologies. The number of groups is necessary for the specialization of interests, but we all share the common interest of ideas that embrace the Open Web. Our event is a call for less fragmentation and to have strength in numbers. We all distribute software using the GPL, we deploy on systems that use it, and for the most part access a common family of tools to produce our work. The products of our work are distributed on the Internet and World Wide Web, and therefore we all depend on open and unfettered access to it.

Bring your open minds. See you there.

Vancouver PHP Users http://vancouver.php.net/

sites for tutorials, reviews

http://developer.yahoo.com/php/
http://www.php.net/manual/en/
http://www.phpit.net/
http://www.elroubio.net/
http://www.sitepoint.com/
http://www.thesitewizard.com/
http://www.phpdeveloper.org/
http://www.phparch.com/

http://www.phpbuilder.com/

http://www.zend.com/zend/tut/
http://www.devshed.com/c/b/PHP/

http://webmonkey.wired.com/webmonkey/programming/php/

Content Management systems
http://moodle.org/
http://www.phpbb.com/
http://drupal.org/
http://wordpress.org/
http://phpadsnew.com/two/

Software tools
http://www.mysql.com/
http://www.sqlite.org/
http://www.apache.org/

http://www.phpmyadmin.net/
http://lamppix.tinowagner.com/

Internet News
http://slashdot.org/
http://news.netcraft.com/
http://www.digg.com

Scripts, etc http://freshmeat.net/
http://sourceforge.net/
http://pear.php.net
http://www.phpclasses.org