From the HashBangCode.com site today there's a new post that revisits filtering with the filter_var function included with the language. The focus in this article is specifically in validating URLs with the FILTER_VALIDATE_URL flag.

Quite a while ago I looked at using the filter_var() function to validate URL's using the FILTER_VALIDATE_URL flag and someone pointed out recently that this function has not only changed since the initial release, but that a number of flags can be added to change the way that this function works.

He lists some of the other flags that are now available that can be used in conjunction with FILTER_VALIDATE_URL to get more fine-grained in your filtering - checks on things like a required scheme, hostname and query string. He includes some code with a set of URLs to run through some tests and output as a table with the pass/fail rank of each URL value. You can see the resulting output here.

WebReference.com has kicked off a new series of tutorials today with this first part of their look at building a personalization system as a part of a bookmarking system.

In this tutorial we will build an online bookmark system. This will be used to create a database for storing all our URL's and their descriptions. There are many commercial and non-commercial applications that offer almost the exact functionality that we will create in our application; the difference is that we have full control over our application, allowing us to tweak it to suit our needs.

The application lets users login/logout, manage bookmarks, gives recommendations based on those bookmarks, show some news headlines and, most importantly, the user must be able to personalize their interface with a custom color scheme and image of their choosing.

This first part gets up to the point of creating the databases (a bookmarks and users tables) and creating the basic template wrapper for the entire site.

Tobias Schlitt has posted some comments on things recently said on PHP's upcoming support for namespaces - specifically on the ideas about naming classes the could conflict with PHP's own internal ones.

Namespaces are potentially coming in PHP 5.3 (does anyone believe?) and people start discussion about how they can even shorten their names from Abstract to aSomething and from Interface to iAnotherthing. I'm a fan of short names. [...] I agree with these rules and am of the opinion that class names must all above anything contain a semantic. Interfaces indicate what you can do with an object, while abstract classes model that different classes have a common base and can be used in the same mannor. And indeed you can add these semantics to names without using the terms.

He gives a few examples, things like Persistable, Configurable and Reflector.

Tobias Schlitt has posted some comments on things recently said on PHP's upcoming support for namespaces - specifically on the ideas about naming classes the could conflict with PHP's own internal ones.

Namespaces are potentially coming in PHP 5.3 (does anyone believe?) and people start discussion about how they can even shorten their names from Abstract to aSomething and from Interface to iAnotherthing. I'm a fan of short names. [...] I agree with these rules and am of the opinion that class names must all above anything contain a semantic. Interfaces indicate what you can do with an object, while abstract classes model that different classes have a common base and can be used in the same mannor. And indeed you can add these semantics to names without using the terms.

He gives a few examples, things like Persistable, Configurable and Reflector.

The Zend Developer Zone has posted two more handy security tips - one concerning file/directory naming and the other about input validation.

From the first tip:

Don't rely on obscure names to keep your application safe. You should always check permissions, test for vulnerabilities with testing tools and keep an eye on your log files for suspicious activity. When designing your applications and web sites though, don't make it easy for bad people to do bad things. Don’t use default or common names for your files and directories.

And from the second:

It's a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as you let your guard down and start thinking "I'm only selling small stuffed animals so how evil can my users really be?" you've lost the battle.

You can catch up on these and the other previous security tips on this page on the Zend Developer Zone website.

The Zend Developer Zone has posted two more handy security tips - one concerning file/directory naming and the other about input validation.

From the first tip:

Don't rely on obscure names to keep your application safe. You should always check permissions, test for vulnerabilities with testing tools and keep an eye on your log files for suspicious activity. When designing your applications and web sites though, don't make it easy for bad people to do bad things. Don’t use default or common names for your files and directories.

And from the second:

It's a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as you let your guard down and start thinking "I'm only selling small stuffed animals so how evil can my users really be?" you've lost the battle.

You can catch up on these and the other previous security tips on this page on the Zend Developer Zone website.

Andrei Zmievski has posted something new to his blog today about a feature of PHP6 that's finally been hammered down - HTTP input (request) decoding.

There have been no fewer than 4 different proposals floated before, but this one combines flexibility, performance, intuitiveness, and minimal architectural changes, and has only a couple of small drawbacks. Let's take a closer look.

He details the functionality - what it is, what's been decided on, and the advantages of the method. The basic approach is a "lazy" one where PHP will only store the request when it comes in, no filtering or anything, until you want to do something with it (i.e. get it via $_GET, $_POST, etc). When the request for data is made, PHP looks at the encoding settings and formats the data accordingly.

Advantages he mentions for this method include removing the guess-work on PHP's part for which encoding the request is and that it removes some of the overhead by not processing the data until it's actually needed.

Andrei Zmievski has posted something new to his blog today about a feature of PHP6 that's finally been hammered down - HTTP input (request) decoding.

There have been no fewer than 4 different proposals floated before, but this one combines flexibility, performance, intuitiveness, and minimal architectural changes, and has only a couple of small drawbacks. Let's take a closer look.

He details the functionality - what it is, what's been decided on, and the advantages of the method. The basic approach is a "lazy" one where PHP will only store the request when it comes in, no filtering or anything, until you want to do something with it (i.e. get it via $_GET, $_POST, etc). When the request for data is made, PHP looks at the encoding settings and formats the data accordingly.

Advantages he mentions for this method include removing the guess-work on PHP's part for which encoding the request is and that it removes some of the overhead by not processing the data until it's actually needed.

Norbet Mocsnik, having just set it up himself, is sharing the steps needed to get DokuWiki set up and working with a simple authentication system.

I promised to investigate the steps needed to set up DokuWiki with the simplest authentication scheme for a friend and I thought others might benefit from it too, so here it is.

There's about fifteen steps in all, including the download/install of the package and creating the basic functionality (like a simple Auth schema - he gives an example). Create the superuser and set up the desired restrictions and you're home free. If you want more information on authentication in DokuWiki, check out this page on the DokuWiki's wiki.

Norbet Mocsnik, having just set it up himself, is sharing the steps needed to get DokuWiki set up and working with a simple authentication system.

I promised to investigate the steps needed to set up DokuWiki with the simplest authentication scheme for a friend and I thought others might benefit from it too, so here it is.

There's about fifteen steps in all, including the download/install of the package and creating the basic functionality (like a simple Auth schema - he gives an example). Create the superuser and set up the desired restrictions and you're home free. If you want more information on authentication in DokuWiki, check out this page on the DokuWiki's wiki.