Extensions in Net::OpenID::Server

[Andrew Garrett]

Hi all,

I've been looking at the documentation for Net::OpenID::Server, and I
haven't been able to figure out how to add extensions support while
using the handle_page method, rather than delving deeper into the
class file.

It looks like the only way to do this right now is to call
signed_return_url yourself and supply an additional_extensions
parameter. This seems suboptimal as you'd have to reimplement the
handle_page method, which contains a whole bunch of tried and tested
logic.

If this is true, and I'm not missing anything obvious, would you be
willing to accept a patch which adds a get_additional_fields method in
the vein of is_identity, to allow for better support of OpenID
extensions?

[Martin Atkins]

Hi Andrew,

I've been slowly working towards reworking Net::OpenID::Server to have a
more similar API to Net::OpenID::Consumer, including extensions support.
The current trunk shows the work so far, with several utility bits
factored out into a Net::OpenID::Common package.

Unfortunately I've not yet had time to finish this work.

If you'd like to work on a patch then I'd suggest looking at
Net::OpenID::Consumer's API model and taking a somewhat similar
approach, so that the two are consistent. The
Net::OpenID::IndirectMessage class, which does the message handling for
Net::OpenID::Consumer, has been shifted out into Net::OpenID::Common so
that it can eventually be used by Net::OpenID::Server.

However, if you'd prefer to do something more simple then I'm happy to
accept that as long as it doesn't block moving to a more comprehensive
and Consumer-like API in the future. Ideally this patch would apply to
the 1.0 maintenence branch rather than to trunk so that it can be
released before the refactoring work is completed.

Thanks,
Martin

[Andrew Garrett]

On Fri, Apr 10, 2009 at 3:24 PM, Martin Atkins <ma...@degeneration.co.uk> wrote:
>> If this is true, and I'm not missing anything obvious, would you be
>> willing to accept a patch which adds a get_additional_fields method in
>> the vein of is_identity, to allow for better support of OpenID
>> extensions?

<snip>

> If you'd like to work on a patch then I'd suggest looking at
> Net::OpenID::Consumer's API model and taking a somewhat similar
> approach, so that the two are consistent. The
> Net::OpenID::IndirectMessage class, which does the message handling for
> Net::OpenID::Consumer, has been shifted out into Net::OpenID::Common so
> that it can eventually be used by Net::OpenID::Server.
>
> However, if you'd prefer to do something more simple then I'm happy to
> accept that as long as it doesn't block moving to a more comprehensive
> and Consumer-like API in the future. Ideally this patch would apply to
> the 1.0 maintenence branch rather than to trunk so that it can be
> released before the refactoring work is completed.

I've been poking at the code for the Consumer object and it seems that
the correct way to set extension fields in Net::OpenID::Consumer is to
call $claimed_identity->set_extension_args before calling
$claimed_identity->check_url (and the args will then be included in
the check URL).

The problem with this approach for Net::OpenID::Server is that the
workflow for Net::OpenID::Server is somewhat different. In ::Consumer,
the idea is that you set the arguments prior to checking an identity.
Ideally, ::Server should have a single callback function whose inputs
are a user object and the provided extension arguments in the
authentication request, and which outputs the response extension
arguments. This makes more sense than manually extracting and acting
on the extension arguments before calling handle_page.

What I'm proposing to do, therefore, is to reuse as much code as
possible from Net::OpenID::Consumer to create such a callback
function, and then pass the return value from that function as the
additional_fields parameter to signed_return_url (line 344 of trunk).

Does this make sense to you? Do you think there's a better
implementation method?

--
Andrew Garrett

[Manu Kaul]

Hi,

Just following up on my previous request. I am trying to use the "Net::OpenID::Consumer" to talk to google authentication services for the hybrid (OpenID+OAuth) protocol. I was wondering if you could assist with some sample code that can help me do the Yadis discovery, read the XRDS document google provides, and then redirect accordingly based on responses. This would help a lot.

Cheers,

Manu 

--

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
- Michelangelo

[Martin Atkins]

Hi Andrew,

This seems sensible. What I had been hoping to do was to add to the
callbacks in Server an object that's roughly equivalent to the
ClaimedIdentity object on the Consumer side, where currently Server just
passes in the identifier URL as a string. There then needs to be
something like VerifiedIdentity which can be returned to indicate
success while including extension responses.

The challenge, of course, is doing this in a way that doesn't break
backward compatibility; the existing callbacks expect to deal in strings
containing identifier URLs.

Net::OpenID::IndirectMessage provides a generic mechanism for dealing
with incoming OpenID messages, including the parsing of extension
arguments. It doesn't currently support *generating* such messages, as
that logic presently lives in ClaimedIdentity. It would be good to pull
it out into a separate class so that the Server equivalent of
VerifiedIdentity can return it.

It'd be nice if we could use the same ClaimedIdentity and
VerifiedIdentity classes on both consumer and server, but if that means
making things excessively complicated then it would be preferable to
have separate classes. ClaimedIdentity and VerifiedIdentity are
currently somewhat coupled with Consumer.