This queue is for tickets about the Net-OpenID-Consumer CPAN distribution.

Report information
The Basics
Id:
41939
Status:
resolved
Worked:
1 minute
Users:
wrog: 1 minute
Priority:
Low/Low

People
Owner:
MART [...] cpan.org
Requestors:
crew@cs.stanford.edu(no email address set)
MART [...] cpan.org
Cc:
AdminCc:

BugTracker
Severity:
Important
Broken in:
(no value)
Fixed in:
  • 1.030099_006
  • 1.11



Subject: Consumer can't handle an OpenID 2.0 setup_needed response
Consumer is expecting user_setup_url to be present in both 1.0 and 2.0, but it does not exist in 2.0. For the 2.0 case, the library should just return the OP's standard checkid_setup URL
Subject: handle_server_response fails on setup_needed without setup_url
In 2.0 it is possible for a response to have openid.mode=setup_needed WITHOUT openid.user_setup_url begin set, which can happen in checkid_immediate mode (google will do this). This screws up the logic of csr->handle_server_response. since if csr->user_setup_url suceeds but returns a blank/undefined url, it drops through to the verified_url case, which then fails with "bad mode". There needs to be a routine of the form sub setup_needed { my Net::OpenID::Consumer $self = shift; if ($self->_message_version == 1) { return $self->_message_mode eq "id_res" && self->message("user_setup_url"); } else { return $self->_message_mode eq 'setup_needed'; } } and then ->handle_server_response should use it, i.e., replace (in line 368 of Consumer.pm): if (my $setup_url = $self->user_setup_url) { return $callbacks{setup_required}->($setup_url); } with if ($self->setup_needed) { return $callbacks{setup_required_no_url} ? $callbacks{setup_required_no_url}->() : $callbacks{setup_required}->($self->user_setup_url); } to test for the setup_required case (and allow for the client to call ->user_setup_url herself in order to set post_grant -- feel free to come up with a better name for the alternate handler).
From: crew@cs.stanford.edu
It also looks like if we're in OpenID 1.1 and we're handling a cancel response, the existing code calls ->user_setup_url used to test for setup_required'ness, which sees that mode is not id_res, sets the "bad mode" error message, and returns false... ... and so we drop through to the next clause to deal with cancel, BUT with the error message spuriously set to "bad mode" which may cause confusion later. Proposed fix in previous method also takes care of this.
On Wed Dec 24 16:36:44 2008, MART wrote:
Show quoted text
> Consumer is expecting user_setup_url to be present in both 1.0 > and 2.0, but it does not exist in 2.0. > > For the 2.0 case, the library should just return the OP's standard > checkid_setup URL
As far as I can tell, there is no notion of a standard checkid_setup URL in 2.0. The only place a setup_url is referenced in the 2.0 spec is in section 14 on how checkid_immediate is handled in version 1.1. As for what 2.0 requires, section 10 says: When receiving a negative assertion in response to a "checkid_immediate" mode request, Relying Parties SHOULD construct a new authentication request using "checkid_setup" mode. in which case, whatever the actual setup URL might be, it'll be getting sent as a 302 response to the subsequent checkid_setup mode message --- it may even be dependent on the particular claimed_id --- and in any event the perl code will never even get to see it. Which, I believe, means that we have an unavoidable API change, i.e., any client code that's expecting setup_url to be set (or even be knowable) and is depending on that as the way to proceed is just going to lose. Meanwhile this bug should probably merge with #54138. The fix that's part of robn's pull request is very much like what's suggested there.
ok, we're doing a slight API change. see SYNOPSIS of Consumer.pm in <a href="http://search.cpan.org/~wrog/Net- OpenID-Consumer-1.030099_006/">1.03099_006</a> (to be uploaded as 1.11 as soon as the various permission bits allow it).
I believe this is fixed in Net-OpenID-Consumer-1.11 If you want to try it out, please make sure you've also installed the latest Net-OpenID-Common. Feel free to re-open (or start a new ticket) if I'm mistaken about this. Thanks for the report and sorry this took so long to get to... - Roger Crew (new co-maintainer as of a few weeks ago)


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.