NAME

BACKWARDS COMPATIBILITY CHANGES

EXTENSION_ARGS v EXTENSIONS

NB: The extensions were previously configured under the key extension_args. They are now configured under extensions. extension_args is no longer honored.

As previously noted, "EXTENSIONS TO OPENID", I have not tested the extensions. I would be grateful for any feedback or, better, tests.

FATALS

The problems encountered by failed OpenID operations have always been fatals in the past. This is unexpected behavior for most users as it differs from other credentials. Authentication errors here are no longer fatal. Debug/error output is improved to offset the loss of information. If for some reason you would prefer the legacy/fatal behavior, set the configuration variable errors_are_fatal to a true value.

The benefit of this version is that you can use an arbitrary number of authentication systems in your Catalyst application and configure and call all of them in the same way.

Note that both earlier versions of OpenID authentication use the method authenticate_openid(). This module uses authenticate() and relies on you to specify the realm. You can specify the realm as the default in the configuration or inline with each authenticate() call; more below.

METHODS

Call to authenticate the user via OpenID. Returns false if authorization is unsuccessful. Sets the user into the session and returns the user object if authentication succeeds.

You can see in the call above that the authentication hash is empty. The implicit OpenID parameter is, as the 2.0 specification says it SHOULD be, openid_identifier. You can set it anything you like in your realm configuration, though, under the key openid_field. If you call authenticate() with the empty info hash and no configured openid_field then only openid_identifier is checked.

You will never call this. Catalyst does it for you. The only important thing you might like to know about it is that it merges its realm configuration with its configuration proper. If this doesn't mean anything to you, don't worry.

CONFIGURATION

Catalyst authentication is now configured entirely from your application's configuration. Do not, for example, put Credential::OpenID into your use Catalyst ... statement. Instead, tell your application that in one of your authentication realms you will use the credential.

In your application the following will give you two different authentication realms. One called "members" which authenticates with clear text passwords and one called "openid" which uses... uh, OpenID.

You can set trust_root now too. This is experimental and I have no idea if it's right or could be better. Right now it must be a URI. It was submitted as a path but this seems to limit it to the Catalyst app and while easier to dynamically generate no matter where the app starts, it seems like the wrong way to go. Let me know if that's mistaken.

EXTENSIONS TO OPENID

The Simple Registration--http://openid.net/extensions/sreg/1.1--(SREG) extension to OpenID is supported in the Net::OpenID family now. Experimental support for it is included here as of v0.12. SREG is the only supported extension in OpenID 1.1. It's experimental in the sense it's a new interface and barely tested. Support for OpenID extensions is here to stay.

Google's OpenID is also now supported. Uh, I think.

Here is a snippet from Thorben Jändling combining Sreg and Google's extenstions–

MORE ON CONFIGURATION

ua_args and ua_class

LWPx::ParanoidAgent is the default agent — ua_class — if it's available, LWP::UserAgent if not. You don't have to set it. I recommend that you do not override it. You can with any well behaved LWP::UserAgent. You probably should not. LWPx::ParanoidAgent buys you many defenses and extra security checks. When you allow your application users freedom to initiate external requests, you open an avenue for DoS (denial of service) attacks. LWPx::ParanoidAgent defends against this. LWP::UserAgent and any regular subclass of it will not.

consumer_secret

The underlying Net::OpenID::Consumer object is seeded with a secret. If it's important to you to set your own, you can. The default uses this package name + its version + the sorted configuration keys of your Catalyst application (chopped at 255 characters if it's longer). This should generally be superior to any fixed string.

TODO

There are some interesting implications with this sort of setup. Does a user aggregate realms or can a user be signed in under more than one realm? The documents could contain a recipe of the self-answering OpenID end-point that is in the tests.

Debug statements need to be both expanded and limited via realm configuration.

LICENSE AND COPYRIGHT

This module is free software; you can redistribute it and modify it under the same terms as Perl itself. See perlartistic.

DISCLAIMER OF WARRANTY

Because this software is licensed free of charge, there is no warranty for the software, to the extent permitted by applicable law. Except when otherwise stated in writing the copyright holders and other parties provide the software "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the software is with you. Should the software prove defective, you assume the cost of all necessary servicing, repair, or correction.

In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who may modify or redistribute the software as permitted by the above license, be liable to you for damages, including any general, special, incidental, or consequential damages arising out of the use or inability to use the software (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the software to operate with any other software), even if such holder or other party has been advised of the possibility of such damages.