Bug #41939 for Net-OpenID-Consumer: Consumer can't handle an OpenID 2.0 setup

Wed Dec 24 16:36:44 2008 MART [...] cpan.org - Ticket created

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

Fri Jan 29 17:48:23 2010 crew@cs.stanford.edu - Ticket #54138: Ticket created

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

Fri Jan 29 18:21:47 2010 crew@cs.stanford.edu - Ticket #54138: Correspondence added

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.

Tue Oct 18 03:51:41 2011 crew [...] cs.stanford.edu - Correspondence added

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.

Wed Oct 19 20:30:43 2011 crew [...] cs.stanford.edu - Ticket #54138: Taken

Wed Oct 19 21:10:18 2011 crew [...] cs.stanford.edu - Ticket #54138: Merged into ticket #41939

Wed Oct 19 21:10:18 2011 crew [...] cs.stanford.edu - Merged into ticket #41939

Sun Oct 23 00:56:32 2011 crew [...] cs.stanford.edu - Correspondence added 1 min

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

Sun Oct 23 01:00:44 2011 crew [...] cs.stanford.edu - Severity Important added

Sun Oct 23 13:56:53 2011 crew [...] cs.stanford.edu - Fixed in 1.030099_006 added

Sun Nov 06 14:39:19 2011 crew [...] cs.stanford.edu - Fixed in 1.11 added

Sat Nov 12 20:29:11 2011 crew [...] cs.stanford.edu - Correspondence added

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)

Sat Nov 12 20:30:18 2011 crew [...] cs.stanford.edu - Status changed from 'open' to 'resolved'

Bug #41939 for Net-OpenID-Consumer: Consumer can't handle an OpenID 2.0 setup_needed response