I also got asked whether there is an example application that shows the usage of the OpenID component. As I already use a very simple application to test the component manually, I pushed this application to GitHub (you can see the application in action on http://openid-example.42dh.com/). I hope this will make it easier for some of you to get started with the OpenID component.

To update, simply replace the OpenID component and the content of the “vendors/Auth” folder (and its subfolders) with the files from the zip archive.

You can download the new version from Github.

The reason it didn’t work is that Google introduced it’s own OpenID discovery protocol as they faced challenges not addressed by the current version (2.0) of the OpenID standard. And this means such OpenIDs are not recognized by current OpenID libraries. For this reason, Google provides with php-openid-apps-discovery an add-on to the PHP OpenID library.

I integrated this add-on into the OpenID component as an optional feature. You have to enable it with:

public $components = array('Openid' => array('accept_google_apps' => true));

I made it an optional feature because it introduces an additional step to the authentication process: the provided OpenID url is sent to Google to figure out whether it is a Google Apps OpenID. And this makes the authentication process a bit slower. Hence I think you should have a choice whether you want to use this feature.

The new version of the OpenID component doesn’t contain any other new features/bugfixes.

You can download the component from Github.

Enjoy!

AX is in principle the “big brother” of the Simple Registration Extension (or SReg for short). Whereas SReg only allows you to retrieve nine commonly requested pieces of information, AX allows you to retrieve any identity information. And theoretically it also allows you to store/update your identity information at your OpenID provider. But it seems like no OpenID provider supports this feature…

Let’s have a look at an example.

First the login method:

// app/controllers/users_controller.php
class UsersController extends AppController {
    public $components = array('Openid', 'RequestHandler');

    public function login() {
        $realm = 'http://'.$_SERVER['SERVER_NAME'];
        $returnTo = $realm . '/users/login';

        if ($this->RequestHandler->isPost()) {
            $this->makeOpenIDRequest($this->data['User']['openid_identifier'], $returnTo, $realm);
        } elseif ($this->Openid->isOpenIDResponse()) {
            $this->handleOpenIDResponse($returnTo);
        }
    }
}

The next step is to implement the makeOpenIDRequest() method. For each attribute we want to retrieve, we have to create an Auth_OpenID_AX_AttrInfo object with the respective attribute type. A list of possible types is available on http://www.axschema.org/types/. Though there are many types defined, OpenID providers usually only support a small subset of those types.

The “1″ we pass to the make() method specifies the number of values we want for this type. In this example it doesn’t make much sense to specify a value other than “1″, but for other types it is theoretically possible to have multiple values (for example you could have defined multiple email addresses). It is an optional parameter and by default it is “1″.

The last parameter specifies whether the value of the attribute is required for our application. This is simply a hint for the OpenID provider so it could display this attribute differently, but it doesn’t guarantee a value is returned. By default this parameter is “false”.

(Update 2010-04-19: Google requires that you set the fourth parameter of the make() method: a string with an alias for the attribute.)

private function makeOpenIDRequest($openid, $returnTo, $realm) {
    $attributes[] = Auth_OpenID_AX_AttrInfo::make('http://axschema.org/namePerson', 1, true);
    $this->Openid->authenticate($openid, $returnTo, $realm, array('ax' => $attributes));
}

Finally, we have to implement the handleOpenIDResponse() method. As we expect only one value for the attribute we specified, we can use either get() or getSingle() to retrieve its value. getSingle() returns the value whereas get() returns an array.

private function handleOpenIDResponse($returnTo) {
    $response = $this->Openid->getResponse($returnTo);

    if ($response->status == Auth_OpenID_SUCCESS) {
        $axResponse = Auth_OpenID_AX_FetchResponse::fromSuccessResponse($response);

        if ($axResponse) {
            debug($axResponse->get('http://axschema.org/namePerson'));
            debug($axResponse->getSingle('http://axschema.org/namePerson'));
        }
    }
}

That’s it.

You can get the new version of the OpenID component from GitHub. If you use SReg in your code and you want to update to this version, please make sure to adapt your code in the following way:

// old
$this->Openid->authenticate($openid, $returnTo, $realm, array('email'), array('nickname'));

// new
$this->Openid->authenticate($openid, $returnTo, $realm, array('sreg_required' => array('email'), 'sreg_optional' => array('nickname')));

Feedback is welcome :)

I don’t know whether this will be the case, it is too early to say. But I doubt it. The project is still backed by the Cake Development Company, which employs some of the core contributors (Larry Masters aka PhpNut, Mark Story). That’s some guarantee that the show will go on. And of course there is a large community.

On the other hand I don’t know how many of the other contributors will remain. And the lack of (official) communication is also not that good for the confidence into the project. What happened? What will be the next steps? Who will take over those vacant roles? See also Matt Curry’s post on this matter.

Anyway, probably the best thing to do now is to drink tea and to wait until the dust settles…

Update (2009-10-23): an official statement has been published in the meantime.

Let’s say we want to add a method to the request handler component. And so we create a new class which inherits from the request handler component:

// app/controllers/components/my_request_handler.php
App::import('Component', 'RequestHandler');
class MyRequestHandlerComponent extends RequestHandlerComponent {
    public function example() {
        // do something
    }
}

To use this component, we have to add it to the $components array of our controller:

// app/app_controller.php
class AppController extends Controller {
    public $components = array('MyRequestHandler');	
}

Nothing new so far. However, a disadvantage of this approach is that you have to use the component in the following way:

$this->MyRequestHandler->isAjax();
$this->MyRequestHandler->example();

Wouldn’t it be nice if we could use it in the usual way?

$this->RequestHandler->isAjax();
$this->RequestHandler->example();

And yes, it is possible. For this purpose we have to override Controller::constructClasses():

// app/app_controller.php
class AppController extends Controller {
    public $components = array('MyRequestHandler');
	
    public function constructClasses() {
        parent::constructClasses();
        $this->RequestHandler = $this->MyRequestHandler;
    }
}

Happy baking!

public function example() {
    App::import('Vendor', 'example', array('file' => 'Example.php'));
    $example = new Example();
    ...
}

This snippet works fine if it is used in an application, but it will fail with a “Class not found” error if the snippet and the corresponding vendors file (“Example.php”) are put into a plugin. The reason for the failure is that you have to use the plugin name as a prefix when importing something from a plugin, even if you use App::import() from within the respective plugin:

// test is the plugin name
App::import('Vendor', 'test.example', array('file' => 'Example.php'));

The consequence of this behavior is that your code has to know in which “environment” it runs if you want to make it really reusable. An alternative is to “circumvent” the application “environment” and to distribute your code, and the required vendors files, as a plugin.

In the OpenID component I solved this problem by determining in which “vendors” directory the required library is. And if it is in the plugin’s “vendors” directory, I set an instance variable $importPrefix with the plugin name. This prefix is then used whenever a file is imported.

Here is the relevant code:

class OpenidComponent extends Object {
    private $importPrefix = '';

    public function __construct() {
        parent::__construct();

        $pathToVendorsFolder = $this->getPathToVendorsFolderWithOpenIDLibrary();
		
        if ($pathToVendorsFolder == '') {
            exit('Unable to find the PHP OpenID library');
        }
		
        if ($this->isPathWithinPlugin($pathToVendorsFolder)) {
            $this->importPrefix = $this->getPluginName() . '.';
        }

        $this->importCoreFilesFromOpenIDLibrary();
    }

    private function getPathToVendorsFolderWithOpenIDLibrary() {
        $pathToVendorsFolder = '';
		
        if ($this->isPathWithinPlugin(__FILE__)) {
            $pluginName = $this->getPluginName();
			
            if (file_exists(APP.'plugins'.DS.$pluginName.DS.'vendors'.DS.'Auth')) {
                $pathToVendorsFolder = APP.'plugins'.DS.$pluginName.DS.'vendors'.DS;
            }
        }

        if ($pathToVendorsFolder == '') {
            if (file_exists(APP.'vendors'.DS.'Auth')) {
                $pathToVendorsFolder = APP.'vendors'.DS;
            } elseif (file_exists(VENDORS.'Auth')) {
                $pathToVendorsFolder = VENDORS;
            }
        }
		
        return $pathToVendorsFolder;
    }
	
    private function getPluginName() {
        $result = array();
        if (preg_match('#'.DS.'plugins'.DS.'(.*)'.DS.'controllers#', __FILE__, $result)) { 
            return $result[1];
        }

        return false;
    }

    private function importCoreFilesFromOpenIDLibrary() {
        App::import('Vendor', $this->importPrefix.'consumer', array('file' => 'Auth'.DS.'OpenID'.DS.'Consumer.php'));
        App::import('Vendor', $this->importPrefix.'sreg', array('file' => 'Auth'.DS.'OpenID'.DS.'SReg.php'));
    }

    private function isPathWithinPlugin($path) {
        return strpos($path, DS.'plugins'.DS) ? true : false;
    }
}

This code is meant to give you an idea of how it could be solved in that specific situation, and not as a solution you can copy 1:1…

Happy baking!

Almost all external libraries are now included in the package to make the installation a bit easier. Included are the required PHP OpenID library and PEAR DB (which is used if you want to store the OpenID data in the database). Not included is the EAUT library as I think this standard is dead (i.e. nobody is using it).

The configuration settings are now set when you add the OpenID component to the $components array of your controller(s):

public $components = array('Openid' => array('use_database' => true));

or

public $components = array('Openid' => array('database_config' => 'name_of_database_config));

The old way, using Configure::write(), is no longer supported:

Configure::write('Openid.use_database', true);
Configure::write('Openid.database_config', 'name_of_database_config');

So, if you upgrade and you use those configuration settings, make sure to adapt your code accordingly.

Last, but not least, I fixed a bug which caused a “class not found” error if you used the component in a plugin.

That’s it. You can get the component from http://code.42dh.com/openid or directly from GitHub.

Happy baking!

That’s nice, however, in our case all JSON views are identical (the same applies for the XML views):

// requires the JSON part from the Zend framework
App::import('Vendor', 'json', array('file' => 'Zend'.DS.'Json.php'));
echo Zend_Json::encode(array('data' => $data));

And so following the default approach would lead to a lot of duplication and many unnecessary folders and view files. And that’s not that cool ;-)

After some experimentation I found a better way.

For each extension I created a folder with a default view:

app
  views
    json
      default.ctp
    xml
      default.ctp

json/default.ctp contains the code I have shown above, and xml/default.ctp would look like:

echo $xml->serialize(array('data' => $data), array('format' => 'tags'));

To tell CakePHP it should render those default views when there is not a more specific view, I added the following beforeRender() callback method to the AppController:

// app/app_controller.php
class AppController extends Controller {
    public function beforeRender() {
        $pathToViewFile = dirname(__FILE__).DS.'views'.DS.$this->viewPath.DS.$this->action.'.ctp';
		
        if (!file_exists($pathToViewFile)) {
            $this->viewPath = $this->layoutPath;
            $this->action = 'default';
        }
    }
}

Happy baking!

Well, the assumption that there is no controller is wrong. There is one, the PagesController, though by default it is “hidden” in cake/libs/controller (unless you baked your project with the bake script, then you will also find a PagesController in app/controllers).

And this means you can specify the helpers you want to use in your static pages in the usual way: by adding them to the $helpers array of the PagesController resp. the AppController (app/app_controller.php), if you want to use the helpers in the views of more than one controller. Please do not edit the PagesController in the cake/libs/controller directory, but copy it to app/controllers and make the changes there.