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.

class MyConstants {
    const AA = 'value';
    const BB = 'another value';
}

echo MyConstants::AA; // output: value

Now, while experimenting with JavaScript (or more precisely with Node.js) I got some constants in my code I wanted to organize with such a constants class. My first, albeit naive, approach looked like:

var sys = require('sys');

function MyConstants() {
    const AA = 'value';
    const BB = 'another value';
}

sys.puts(MyConstants.AA); // output: undefined

However, as you can see, this doesn’t work. One reason is that const “[c]reates a constant that can be global or local to the function in which it is declared.”. So it isn’t possible to create a constants class like I imagined…

This means we have to emulate a constants class by using static properties and relying on the naming convention that names of constants are uppercased (i.e. the “constants” are technically not constants and their value can be changed):

var sys = require('sys');

function MyConstants() {
}

MyConstants.AA = 'value';
MyConstants.BB = 'another value';

sys.puts(MyConstants.AA); // output: value

If there is a better approach, please let me know.

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.

h1
  height: 118px
  margin-top: 1em

.tagline
  font-size: 26px
  text-align: right

However, with the upcoming Sass 3 (it is planned to be released on May 10, 2010) a new format gets introduced: SCSS (Sassy CSS). It is a superset of CSS, i.e. each CSS file is automatically a SCSS file (you simply have to change the file extension from “css” to “scss”). So the example from above in SCSS is just plain CSS:

h1 {
  height: 118px;
  margin-top: 1em;
}

.tagline {
  font-size: 26px;
  text-align: right;
}

Not that exciting, isn’t it?

Where SCSS shines is when it comes to the integration of the Sass features (nesting, variables, and mixins) into this format. The devs did a very good job to make it feel like those features are native CSS.

Let’s have a look at some examples.

Nesting:

#header {
  background: gray;
  a {
    background: white;
    color: black;
  }
}

Variables:

$background_color: gray;

#header {
  background: $background_color;
}

Mixins:

@mixin red_border($border_width) {
  border: $border_width solid red;
}

#box_a {
  @include red_border(5px);
}

#box_b {
  @include red_border(10px);
}

Personally I really like the new SCSS format, and I can only recommend to try it out for yourself.

One tool that helps with this is Hydra. It allows you to distribute tests across multiple processors and machines, and currently supports the Test::Unit, Cucumber, and RSpec frameworks. In this article I will focus on running Cucumber tests on a single machine.

As Hydra is distributed as a Ruby Gem its installation is pretty simple:

gem install hydra

After that, you have to add Hydra to the Rakefile of the respective project. And you have to specify the Cucumber task and the files it should use.

# Rakefile
require 'hydra'
require 'hydra/tasks'

Hydra::TestTask.new('hydra:cucumber') do |t|
  t.add_files 'features/**/*.feature'
end

As last step you have to create a “hydra.yml” file in the “config” folder of your project. Here you define whether the tests should run locally, and how many runners Hydra should start. Runners correspond to processors, and so the setting below is for a dual core machine.

# config/hydra.yml
workers:
  - type: local
    runners: 2

With everything set up, you can now run the tests with the following command:

$ RAILS_ENV=test rake hydra:cucumber

To verify whether there is really a speed gain when running the tests in this way you have to do some kind of a benchmark (see the example below), because running something on multiple processors doesn’t necessarily mean it is faster…

Happy testing!
 

—
For my (unscientific) benchmark I ran my test suite (consisting of 12 files with 43 scenarios and 193 steps) with the following commands five times and averaged the results:

$ time cucumber features
$ time rake cucumber
$ time RAILS_ENV=test rake hydra:cucumber

In the first scenario I ran the benchmark with no other user applications running, i.e. both processors were available for the task at hand. From the results you can see that using Hydra in such a scenario is the fastest solution.

cucumber: 24.1s
cucumber with rake: 31.4s
hydra:cucumber: 22.4s

In the second scenario I ran the benchmark in a typical development environment with many open applications, i.e. around 1.5 processors were available. This time, using Hydra is not the fastest solution, the overhead is bigger than the speed gain from having more than one processor .

cucumber: 25.9s
cucumber with rake: 34.3s
hydra:cucumber: 30.6s

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!

describe BlogPost do
  before do
    @blog_post = BlogPost.create :title => 'Hello'
  end

  it "does something" do
    @blog_post.should ...
  end

  it "does something else" do
    @blog_post.should ...
  end
end

However, recently I stumbled upon a cleaner approach in a presentation (from which I borrowed the examples in this article) by Jon Larkowski that makes use of RSpec’s let() method. With this approach, the example from above looks like:

describe BlogPost do
  let(:blog_post) { BlogPost.create :title => 'Hello' }

  it "does something" do
    blog_post.should ...
  end

  it "does something else" do
    blog_post.should ...
  end
end

At first this looked quite magic to me and I had no clue how it worked. Though a look at the source of the let() method reveals the magic (the code should be self-explanatory, or else please leave a comment):

def let(name, &block)
  define_method name do
    @assignments ||= {}
    @assignments[name] ||= instance_eval(&block)
  end
end

Happy RSpecing!

After following the instructions for creating a new Rails 3 app (using the –database=mysql parameter for the “rails” command) I noticed that the application tried to access the (not existing) production database. That was a bit strange, because I expected it to access the development database as I set the RailsEnv option of Passenger accordingly:

# for example in /etc/httpd/conf/httpd.conf
RailsEnv development

The reason this doesn’t work is because the generated application contains a “config.ru” file. In this case, Passenger treats the application as a Rack application and not as a Rails application. And so the RailsEnv setting is ignored as it is Rails-specific…

There are two ways to run the application in development mode: you can either remove the “config.ru” file (and keep the RailsEnv setting) or you can set the RackEnv option:

# for example in /etc/httpd/conf/httpd.conf
RackEnv development

Have fun with Rails 3 :)

In this case, the following steps might help to fix this issue:

• Ensure you have Curl and OpenSSL installed
• Enable the Curl and OpenSSL extensions in your php.ini (on Archlinux this file is found in /etc/php/):

  extension=curl.so
  extension=openssl.so
  

• Restart your web server

Now the error message should disappear and you should be able to log in with the Google OpenID.

—-

That’s it for 2009. It was a rather lazy year on this blog from my side (I didn’t even manage to do a redesign…), and so I hope I will be a bit less lazy with writing on this blog in 2010.

Anyway, thank you for reading this blog, and for all your comments and emails. A Happy New Year everyone & cu in 2010 :)

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 :)