Maugrim The Reaper's Blog

There are a lot of cool people on the PHP Developer Network forums. One of them is Edward Z. Yang.

On June 20th, Edward released HTML Purifier 2.0.0. HTML Purifier is a standards compliant HTML filter written in PHP. It uses a whitelisting approach and outputs standards compliant code, even if originally scrambled into an unintellible mess. It uses functionality in the background based on Tidy's behaviour (so your preferred DTD is adhered to while filtering).

It's purpose, in case you're not familiar with HTML filter libraries, is to filter HTML user input to ensure it only includes whitelisted elements and attributes, and absolutely no XSS. The site contains a page dedicated to tests against the infamous http://ha.ckers.org/xss.html exploits. There's even a demo page for testing it against your own possible exploits.

For my own part, HTML Purifier is probably the finest HTML filtering library in PHP at the moment. Its design is top notch, it's a doddle to extend, and the API is intuitive for whitelisting (see the Advanced API). The library's website has a stock of documentation for users and developers - including some useful tips for improving performance. Go get a copy and give it a whirl.

Since I have a three track mind (but only one dedicated to PHP), I'm stuck with another OpenID post. Over the weekend, I managed to grab a few hours to dig around my OpenID library with the ultimate development tools: patience and experimentation. There are also a few integration tests as a safety net though . So I will be sending a copy around to a few people including Dmitry who has posted a Zend Framework proposal for OpenID on the wiki (which is currently down, as usual, so I haven't managed to add a comment on it yet - should be more stable in the near future I hear).

The refactored library changed a few aspects of the original code I wrote last Autumn. The original placed a lot of responsibilities in the Consumer class which meant it was very difficult to actually change things without knock on effects elsewhere. What I've refactored towards is a splitting of the OpenID process based on three categories: Request, Redirect, Response. The OpenID Specification is all about communication, and this type of splitting seems to have worked out very well. The other change was to centralise all values which are effectively constants to the top-level OpenID class. This class also manages the current version via a static public method - OpenID::setVersion().

So what does the library not include (always a good question!).

1. XRI Support is not complete. I need to add an interface to the Yadis object to extract an XRI's Canonical ID which is the actual value used as an OpenID claimed identifier.
2. Stateless Mode is not supported. Also called Dumb Mode, it's necessary when the server cannot store state between requests. Since PHP is perfectly stateful I omitted it for now.
3. Good session integration for frameworks. The library currently directly accesses $_SESSION under an "OPENID_SESSION" namespace. For the Zend Framework and others which have a Session class (e.g. Zend_Session_Namespace) this may not work well if sessions are being written to the database, or session expiry dates being set.

What does it support?

It supports almost the entire OpenID 2.0 Authentication Specification (draft 11 since it's not finalised). It also transparently covers a few common edge cases such as OP Servers which do not always return an "ns" namespace value in responses. It also downgrades and tracks the association type when an OP cannot use SHA256 (e.g. a number of PHP4 based providers). It also supports OpenID Extensions - you can add extension types quickly to the current list (i.e. the Simple Registration Extension (sreg) for now).

Improvements over original library?

It now has wider support for Diffie-Hellman and HMAC using one of mhash or hash extensions (both crytographic algorithms are segregated to their own class also). Classes are now lowly coupled, so maintenance and individual class testing is simpler. Logic is more dispersed across smaller methods - again making it easier to maintain, test, and modify discrete chunks of logic. I've also centralised the constant values, and amended the API to be similar to that used by JanRain's PHP4 library. There are of course differences from JanRain's API but the flow is very similar.

Other stuff?

Except for some API improvements I should make, it includes a functional Yadis implementation. A task for later is allowing the OpenID library check whether an OP supports extensions like Sreg by checking the list of available Service types discovered by the Yadis protocol. This only needs a minor change - I first need to check whether a missing sreg service in an XRD document is a definitive sign it is not supported, or whether it's entirely optional to show it as a service. (More spec reading this evening ).

Aside from an example to be passed to the Zend Framework proposal, the library in it's refactored form will be proposed to PEAR. I think I'll propose Services_Yadis first since it's a component of the larger OpenID scheme.

As a follow on from my previous entry about OpenID in the Zend Framework, I've been in brief contact with Dmitry Stogov across a scattering of emails. Dmitry posted his OpenID proposal for the framework over at the Proposals Wiki earlier in the week. I'll be passing comments on this whenever possible (i.e. whenever the phone stops ringing this weekend ).

The main differences between Dmitry's code and my own are hard to really explain. Dmitry's sample code is very brief, to the point, and gets OpenID 1.1 done. There is no OpenID 2.0 compatible consumer since the code omits Yadis, but it should catch most HTML based discovery elements from an OpenID alias. It doesn't capture everything perfectly however, and there's still a ton of coding and test work required to get it working robustly. The difference to my library is pretty big as a result. I do a lot of abstraction in my coding so I don't have a single Consumer class - I have about 5 classes working in unison handling various authentication stages. I also have the cryptographic and math logic split into free standing components (see the PEAR proposals below for example). It's a heavier set of code which evolved over a much longer time and so naturally covers a lot more of the specification and it's edge cases.

It's actually very hard to comment constructively rather than simply handing over my code which probably says a lot more all by itself. I really really need to get my code refactored fully at the weekend so I can slap a New BSD License on it and hand it over - I can't keep referring to empty air .

Now what's this about PEAR?

After my weekend blog entry I took onboard Greg Beaver's prompting in the comments. Greg noted that PEAR was looking for an OpenID implementation. One of the reasons I had for not going to PEAR before was that JanRain (the maintainers of PHP OpenID - a PHP4 library) had a proposal over there. It looks like that proposal has now stalled and JanRain are no longer interested in persuing a PEAR route. Among the listed reasons are the PEAR Coding Standards and the difficulty of migrating the library to PHP5. I think their reasons are a bit odd, but their choice. The PEAR conditions make a lot of sense if you intend setting a high quality standard for code.

Anyway, I've agreed to port my OpenID library to PEAR as a PHP5 package. I checked with the mailing list, and the approach I've taken in splitting the library across a number of freestanding components hasn't seen any objections. On the flipside, it does help by providing upgrades to existing PEAR Encryption packages which are not yet migrated to PHP5 versions.

To get the process rolling I have proposed two packages so far: Crypt_HMAC2 and Crypt_DiffieHellman. These are the two cryptographic areas an OpenID Consumer must implement. The code is fairly intact from what would have been the Zend Framework Zend_Crypt_* proposals.

The next PEAR proposal will likely be the heavyweight Services_Yadis, a reflection of a similar proposal for the Zend Framework. Yadis is an XML based service discovery protocol - required for OpenID 2.0 Consumers. In my OpenID implementation it's also the component solely responsible for managing and validating XRI identities and finding their OpenID required CanonicalID values.

In using PEAR for years, I've never proposed a package before. It was quite a pleasant surprise to find out how easy it was. Following the PEAR Coding Standard is already a habit and building example installable packages for a proposal just requires minimal reading of the PEAR_PackageFileManager documentation, which is useful in generating those package.xml files which tells PEAR about the package and install locations of files. I also seem to have joined up to PEAR just in time for a future announcement regarding PEAR2. Travis Swicegood already blogged about this earlier.