PHP comes with two random number generators named rand() and mt_rand(). The first is just a wrapper around the libc rand() function and the second one is an implementation of the Mersenne Twister pseudo random number generator. Both of these algorithms are seeded by a single 32 bit dword when they are first used in a process or one of the seeding functions srand() or mt_srand() is called.

He looks at how its currently implemented, some examples of bad methods to get "random" numbers, how shared resources are a problem and an example of a cross-application attack (the application in more than once place using the same method for getting random numbers).

In the comments he recommends either grabbing from /dev/random (if you're on a unix-based system) or making the creation of your numbers a bit more complex to include things the outside world wouldn't know.

That's because any number preceded by 0 is treated as an octal number, and 9 is an invalid octal number. [...] The silly thing is that hardly anyone uses octal nowadays, but it continues to be part of the C, C++, Java and PHP standards. The mistake is also very common.

There's not much way around it, he notes - the format's been in use for a long time now and is so ingrained in just about every C-based language out there that it's "too deeply imprinted in modern compiler DNA" to take out.

Someone reported a bug in ADOdb, the open source db library i maintain. I went crazy for half an hour until i realised the problem.

According to him, "if you expect the above code to produce the same values, you are sadly mistaken". His example gives an interesting result for the first echo statement - not echoing the 9 in the first character like it seems would make sense. Check out his post for the code and try it out for yourself.

The problem is if you've done any calculations to arrive at these numbers they might actually be stored as 71.00000000001. Now if one of them is stored that way and the other isn't and you compare the two to see if they are equal you'll get a FALSE as the response, even though they should be the same. This isn't a bug, it's how floating point comparisons are designed to work.

In order to help combat this, he's provided two functions - one in PHP and one in Javascript - that compare the numbers in a more "sane" way that someone using them to store, say, currency values might want to use to compare them.

Most PHP pager classes can work just fine with GET parameters, correctly forwarding them through the pages. Few of them let you control the navigation links they create, though. This can be particularly annoying when you have some nice urls (thanks to some mod_rewrite rules o to your hand-crafted front controller) and the pager class can't respect them, showing the real, ugly links to the world.

If the above scenario is not new to you, then you should probably have a look at PEAR::Pager. It's a fully customizable package that should satisfy all your needs, including your preferred link format.

In his examples, he provides the mod_rewrite rules to use, a sample PHP script that would normally use the $_GET values (in an ugly URL) to paginate the results. He also compensates for if the page number is actually a part of the path and not just at the end of the file name.

Poor validation is a key weakness many scripts are guilty of, enabling security exploits. The Validate package can be used to validate any data, and is especially useful for validating user input.

There are also related packages that apply specific validation rules according to geographic location. I don't cover these packages in this article, though once you've grasped the basics of the main Validate package, using these won't present much of a challenge.

They introduce the package by showing a quick install of it, including dependencies. From there, it's examples of different validation types:

• email addresses
• numbers
• strings
• dates
• URLs

And it wouldn't be a tutorial without some code, so for each example there's a snippet or two and a breakdown of its usage.

In this second part of a three-part series, we take up the topic of server-side validation. By the time you finish this article, you'll have the general guidelines for how to build a form validating class. You'll use some PHP built-in introspection functions, along with regular expressions, to assist you in building this class.

They create several functions, including validateEmpty, validateInteger, validateNumber, validateRange, and validateEmail. Each one (obviously) serves their own purpose, and some are more complex that others (validating an integer versus a valid email address), but they walk you through each, showing you plenty of code and explainations along the way...]]> Tue, 24 Jan 2006 06:57:09 -0600