Openid and Yadis
Today saw the much anticipated release of the first production release of the Zend Framework. I’ve been following the project keenly since last Summer, so congratulations to the developers, contributors and the ever omniscient Zenders for their hard work to date!
The Zend Framework has evolved into a loosely coupled, extremely flexible and easy to modify framework. Built across months of debate, hard work and the occasional emotional tirade (as I’ve been guilty of recently ) the 1.0.0 release now carries a stable API and an impressive array of features. Personally, I’m impressed on the insistence of obtaining a stable API by a fixed date at the cost of some completion concerns. It really is essential these days that adopters of a new technology are given the stability they need to get things done effectively now – not months down the line. I know from migrating several applications across 0.6, 0.7 to 0.9 that the lack of stability is a costly issue, much more costly than a few missing or incomplete features one can workaround for the moment.
I know most people will shout MVC a dozen times before collapsing into a state of ecstatic delirium, but there is a lot more to the Zend Framework than MVC. The MVC components are absolutely essential, but are not the sum total of the Framework.
Over the months I’ve come to appreciate the fixation on web services. Easy integration with web services is hugely important these days – from the simplicity of agregating RSS/Atom feeds to the complexity of building your own RESTful service. The Zend Framework is all geared up on web service steroids with support for RSS/Atom feeds, Google, StrikeIron (which is quite cool), Yahoo, Flickr, and the usual suspects. Not to mention the more general support offered by Zend_Rest and Zend_XmlRpc.
My other favourites are the i18n support offered by Zend_Locale, Zend_Date and Zend_Translate. For those who will use Zend_Validate classes, many of the character string validators attempt to use a Unicode mode so you’re not tied to the usual ASCII range. These components make it very easy to internationalise your application, support multibyte languages, and minimise the mountain of work a typical PHP application needs to go international correctly. Zend_Uri even has support for validating a number of Unicode IRIs (internationalised resource identifiers). Hopefully support for this improves over time given how many domain names are availing of IRI support – especially now that many of the popular browsers (incl. IE7) have built in the IDNA standard.
Finally, the Zend Framework website has seen a few changes. You can read the current future roadmap over at http://framework.zend.com/whyzf/future/. It’s interesting to see both OpenID (and to a lesser extent Vista’s CardSpace) mentioned along with support for the YAML format. I’ve worked with both extensively and have related proposals (Dmitry Stogov is leading the OpenID proposal, me the related Yadis Protocol one, as well as a Zend_Yaml proposal) on the ZF Developer’s Wiki. OpenID is a very interesting authentication service so spare the proposals a read if you have a chance .
On a last unrelated note:
if you’ve read or intend reading my Acceptance Testing with PHPUnit/Selenium article on Devzone you should be aware that Sebastion Bergmann just announced the release of PHPUnit 3.1.0 which replaces the requirement for PEAR’s Testing_Selenium with an internal implementation. I’ll be testing later on to see if an article addendum is warranted.
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.
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.