Skip to content

Home

Authentication services

When I designed the back-end for this blog, I built in the capability for understanding multiple authentication sources. It currently supports three different sources: one of which is local and the other two are CVS servers. By supporting remote authentication sources, I spare myself from having to implement a lot of the user management gumph that is needed to support it (email address verification, password management and so on). While this is good for me, if the authentication is perceived as happening on my site, people don't feel quite so comfortable entering their off-site credentials, because they don't really know what I do with their data.

I'm currently going through one of those phases where I'm thinking about what I'd put into "netevil 2.0", and one of those things is adopting support for authenticating against well-known external sites. Ideally, I'd like people to be able to login to Yahoo or Google and then have some way for my blog to determine a subset of their profile data when they post a comment.

This single-sign-on (SSO) concept is nothing new; Microsoft's passport has been around for quite some time now, and there are newer open specifications being designed by SXIP and the Libery Alliance. Both of these projects are working on IETF draft standards for identity management and federation protocols to facilitate SSO. SXIP is very open and has an implementation in PHP that you can download and use. Liberty feels somewhat closed, and has no reference implementation in any scripting language, which immediately creates quite a high barrier to entry for a large portion of the web developer population.

So, we have one established SSO provider (MS passport) and two entities developing SSO technology. Why haven't I seen any sites, aside from passport enabled sites, using anything like this stuff? I think part of the problem is that SXIP and Liberty are providing the technology but not providing the actual authentication services. Taking SXIP as an example, if I want to SXIP enable my site I need to direct users to a SXIP homesite where they can create an identity, and which can then authenticate them with my blog. The problem is that there aren't really any SXIP homesites out there, so I'd need to implement one myself, and we're back at square one.

I think it would be a huge thing if the big guys (yahoo, google) could implement something like SXIP and allow third-party applications to authenticate users against them. Yahoo is almost there already--if you look at the Flickr API you'll see that you can have flickr authenticate users and provide your application with an authentication token (subject to approval from the user). From that token you can obtain the name of the user, and use that to render the name of the person submitting comments to your site.

It'll be interesting to see what, if any, developments are made in this area.

Extending PHP

While poking around the disks in my linux box, I found my materials for a session on extending PHP that I originally gave as a 3 hour tutorial at PHP{Con West 2003.

Sadly, I seem to have lost the working C code (libares bindings for PHP), but all the relevant parts can be found in the comprehensive PDF I made from the slides: Extending PHP Slides (PDF). The content is based on PHP 4, but should still be applicable to PHP 5.

As it happens, Mike Wallner has recently built his own PECL extension for libares, which is much more complete (and complex) than my examples.

Programming PHP

The second edition of Programming PHP was recently published. The O'Reilly press release said:

Rasmus Lerdorf and Kevin Tatroe provided the guidelines for this book. The newest author is Peter MacIntyre, a Zend Certified Engineer with more than five years experience in PHP. Wez Furlong and Chris Shiflett also contributed. Furlong modernized the "Extending PHP" chapter, and Shiflett brought his renowned expertise in updating the "Security" chapter.

  • in php
  • 1 min read

Implementing PDO drivers... using PHP

An interesting development that sprang from a conversation I had with Sara Golemon at the Zend Conference last year: user-space PDO drivers. If you don't know what I'm talking about, it's the ability to be able to define classes in PHP that implement PDO drivers.

It'll be interesting to see what people make of this. I was chatting about it with Chris last night, and he suggested that it might serve as a useful bridge for systems that have no native library connectivity. PDO::User could be used to shoe-horn in connectivity without having to radically rewrite other application code. Another similar idea is to map older database extensions as PDO drivers.

It's still early days yet, but it will be interesting to see where this goes. Thanks Sara :)

Just the facts, ma'am

It looks like this PHP vs ASP.NET article really struck a nerve with Joe Stagner.

Joe's response is perhaps a little pro-Microsoft (you can't really blame him for that--he does work there :-) but the essence of his response rings true; there's nowhere near enough factual data in the OTN article to make a balanced decision one way or the other.

To be fair to Sean (the author of the OTN article), it does say "Opinion" across the top of the page and the byline is "One developer's view of the pros and cons of the two most popular means of building web applications", but it's easy to forget those once you're into the article.

I don't want to get caught up in a comparison myself so I will say that a good systems architect will take into account a wide range of factors before arriving at a decision about what is the right combination of tools for the job, and that Joe's response reminds us that projects for really big customers tend to have different non-technical criteria to what I'm going to call the "typical" PHP customer. By non-technical criteria I mean things like business or political concerns--things like corporate mandates for technology choice, considerations based on the skill-set of a possibly very large existing IT staff and so on.

In plain english, it may cost next to nothing to employ PHP developers to build an application, but it may cost a small fortune to "re-tool" the support infrastructure to be able to effectively deploy that application in an exclusively Microsoft/Windows environment. In this situation PHP is not the better solution, even if it would have gotten the job done in less time and with fewer lines of code.

The point of this blog entry is to encourage people to think a bit harder before they sit down to write. You should try to qualify your observations by talking about the environment and other circumstances that apply to situation and then back it up with some factual data. This will turn anecdotal stories into a useful technical resource.

more PDO PECL releases

PHP 5.1.3 was just released, including the latest PDO and PDO drivers. If you're still running older releases of PHP you should probably upgrade. If you don't want to upgrade the PHP core then you'll be pleased to know that I've also released the PHP 5.1.3 versions of PDO, PDO::MYSQL, PDO::PGSQL, PDO::SQLITE and PDO::ODBC to PECL--these are the versions that I've had time to personally test.

These are identical to the code in PHP 5.1.3, with the exception of PDO::ODBC, which includes two additional bug fixes that didn't make it in time.

Enjoy!

On a related note, I noticed that people were downloading PHP 5.1.2 and then trying to build older PDO drivers from PECL into it, and then filing bugs when it didn't work. Don't do that; it really doesn't make sense. As a general rule, PHP 5.1 and higher bundle PDO, so if the version of PHP you are using is newer than the latest PECL package, stick with the version of PDO that ships with PHP. If the PECL package is newer, then go for that instead.

  • in Blog
  • 1 min read

A kick in the nuts

Flurong!?. I thought RSS was supposed to help avoid things like mis-spelling the names of the people you're syndicating. Double-nut-pain is scored for making the same typo twice. Ouch. :)

I know that phpdeveloper.org produced by human hands, and I'm not knocking the summaries at all; it would just be nice to have at least our names correctly spelled, in case they are re-syndicated from there and the typo propogated around the 'net.

  • in php
  • 2 min read

Undefined behaviour

or, why I find the Solaris manual pages amusing.

In this thread on the php internals list, Kevin is asking why the handling of whitespace in certain PDO DSNs is inconsistent. I go on to point out that the manual doesn't say anything about whitespace in DSNs, and that all the documented examples have no whitespace around the DSN parameters.

His response was: 

   but in this example we have a space and it works
   mysql: host = localhost; dbname=test

And another that I got via private email: 

   But it doesn't tell me I should avoid spaces either.

This is an example of undefined behaviour. The PHP manual doesn't define what happens when you put whitespace in there. That doesn't tell you anything at all about whether you should or should not do that. It might work now, and it might work next week. In 6 months time, when you application is widely deployed and someone changes an apparently unrelated part of their system, it might NOT work and might result in someone getting paged at 3am trying to figure out what the mysterious problem is.

If you take a look at the Solaris manual pages you'll see evidence that the folks at Sun have run into people reporting problems with undefined behaviour. My favourite so far is in one of the pthread manual pages where it describes in one short paragraph what a particular function does, and then proceeds to describe a very large number of use cases that are undefined, along the lines of: 

   If you do X, then the behaviour is undefined.
   If you do Y, then the behaviour is undefined.
   If you do Z, then the behaviour is undefined.

and so on for a couple of pages. This is an example of really good documentation; it only really needs to tell you how to use it, and assuming that people read the manual and follow the examples, they shouldn't run into problems. Explicitly stating what constitutes undefined behaviour is a sign that the documentor has good technical understanding of the routine and, almost certainly, too much past experience with tracking down problem reports from people that are misusing the API.

While really good documentation for everything would be nice to have, it's not always available. In circumstances where the documentation doesn't tell you about what happens when you do a particular thing, you should treat it as though the documentation says "If you do FOO, then the behaviour is undefined". If you need to find out a definitive answer, contact the author/vendor and ask them. When they give you an answer, listen to them. They've said what they've said for a reason.

PDO::MySQL slides from MySQLUC 2006

I tried to upload my slides from the conference, but run into problems with a firewall somewhere, so they've had to wait for me to return home.

So, here we are: Using MySQL with PDO (PDF).

This was my first MySQL users conference, and it seemed to go well. Truth be told, I'm not a database fanatic (which is ironic considering my involvement with PDO), so I didn't find a lot of the material to my taste. I did learn a few things from Jim Winsteads embedded mysql talk (something I bet he'll be surprised to hear :) and also Hartmut Holzgraefe's mysqli talk. I also got to chat to Monty about the issues I mentioned and meet some new faces, including my Evil sysadmin, some old and some older faces (Hi Sterling :)

The conference was quite big; 1500 attendees, 6 tech tracks (there were a couple of other non-tech tracks too, but I forget exactly what they covered) and a lot of BOF sessions. If MySQL is your bread and butter, you might want to consider attending the next one.

  • in php
  • 1 min read

Using PDO::MYSQL ?

I've recently discovered a few things about how the mysql client library does things that seem a bit silly to me, so I'm going to share them with you.

  • native prepared statements cannot take advantage of the query cache, resulting in lower performance.
  • native prepared statements cannot execute certains types of queries, like "SHOW TABLES"
  • native prepared statements don't correctly communicate column lengths for certain other "SHOW" queries, resulting in garbled results.
  • calling stored procedures multiple times using native prepared statements causes the connection to drop.

I recommend that you use the following attribute when working with PDO::MYSQL, available in the current PHP 5.1.3 release candidates and snapshots: 

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

This causes the PDO native query parser to be used instead of the native prepared statements APIs in the mysql client, and effectively eliminates those problems.

I'll admit that the last point could well be a bug in my code; since I'll be at the MySQL Users Conference next week, I should be able to sit down with the right people and fix it.