OpenID login fails for delegated OpenIDs.

I've run into this, too, and it has nothing to do with the TLD involved. It seems that Drupal isn't following delegated (sometimes called claimed) OpenIDs properly.

To reproduce:

1. Get an openID from your favorite provider.
2. Follow the directions at http://www.intertwingly.net/blog/2007/01/03/OpenID-for-non-SuperUsers#cl... or https://www.myopenid.com/help#own_domain to use another URL of your choice with your existing OpenID.
3. Try to log in to a site running Drupal 6 with the core OpenID module using the URL you just set up.

You will receive the error "Sorry, that is not a valid OpenID. Please ensure you have spelled your ID correctly."

I marked this one as critical because anyone who uses thier own URL as their OpenID without running their own server won't be able to log in at all. This is one of the main arguments for OpenID -- that one can use one's blog, web site, or other existing place on the web as one's identity in a consistent manner. It's beyond my knowledge to fix, but I'll be happy to review the patch.

I use delegation from my own blog to myopenid.com and it works. so there is a problem here but it isn't all pervasive.

deleted

I am having the same problems with delegated openID. Works on other sites but not Drupal sites.

i think this is the problem i have in 6.8. When manually adding my openid in my account. I can add the openid fine, but when i try to logon after, its not working. But, when i modify the openid_user_identities function in openid.pages.inc(line 37):

$identity = $result['openid.claimed_id'];

To This:

$identity = $result['openid.identity'];

then i can add my openid(https://launchpad.net/~username), and once i have sign in, launchpad return my openid identity(https://login.launchpad.net/+id/XXXXXX) witch is added instead of the openid i entered earlier. After that i can login with openid just fine.

ditto and subscribe

SUBCSRIBE

pls can someone have a look ? thanks !

the first user on our new site tried logging in via openid .... guess how it finished :(

So I tried it on a fresh drupal instalation : festivia.susino.cz (local village choir, but famous :)

I have this old blog on http://razzere.blogspot.com/, it told me to use "http://razzere.blogspot.com/" as my openID. So I did.

I ended up with a blank page showing this error :
error:Invalid AuthRequest: 768: Invalid value for openid.ns field: http://openid.net/signon/1.0

this is the request (I added newlines for it to fit) :

http://www.blogger.com/openid-server.g?openid.ns=http%3A%2F%2Fopenid.net%2Fsignon%2F1.0&openid.mode=checkid_setup
&openid.identity=http%3A%2F%2Frazzere.blogspot.com%2F&openid.claimed_id=http%3A%2F%2Frazzere.blogspot.com%2F
&openid.assoc_handle=oida-1234568470492--1347132080&openid.return_to=http%3A%2F%2Ffestivia.susino.cz%2F%3Fq%3Dopenid%2Fauthenticate%26destination%3Dnode
&openid.trust_root=http%3A%2F%2Ffestivia.susino.cz%2F&openid.sreg.required=nickname%2Cemail&openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1

When I tried the same on http://www.zooomr.com/login/openid/, it worked fine (a blogger page showed up, asking me whether that's what I want).

Pls let me know if I can be of any other help (that site might move soon, so i can probably setup a new one ...).
Thanks a LOT

Problem affects my OpenID (http://samj.net/) with version 6.10

Sam

same problem here - subscribe

Issue still present in 6.12

As mentioned in #5, there is a problem with $response['openid.claimed_id'] not always being present.

Trying to call openid_discovery($response['openid.claimed_id']) when $response['openid.claimed_id'] is undefined fails silently on Drupal 6 (because E_ALL is disabled) and gives an error in Drupal 7. However, we don't want to do the discovery when $response['openid.claimed_id']. Instead, we should use the $claim_id that we used in the original request.

Here's a patch for Drupal 7. It also applies to Drupal 6 with some offset.

Thanks to Damien Tournoud for helping me make sense of this patch.

This all comes from the OpenID specification, section 14.2.1 (emphasis mine):

"openid.claimed_id" is not defined by OpenID Authentication 1.1. Relying Parties MAY send the value when making requests, but MUST NOT depend on the value being present in authentication responses. When the OP-Local Identifier ("openid.identity") is different from the Claimed Identifier, the Relying Party MUST keep track of what Claimed Identifier was used to discover the OP-Local Identifier, for example by keeping it in session state. Although the Claimed Identifier will not be present in the response, it MUST be used as the identifier for the user.

But the patch is slightly wrong: we need to explicitly set $response['openid.claim_id'] if not already set in the response (and when OpenID 2 is used), because this value is used downstream (for example in openid_authentication()).

Edited: I was wrong.

We need to improve the comments of that section of the code, and add a reference to section 14.2.1.

By the way, this particular issue is a regression introduced by SA-CORE-2009-008, and I doubt it will solve the issue the original poster was facing.

I don't understand the circumstances that trigger this bug.

-  if ($service['version'] == 2 && $response['openid.claimed_id'] != $claimed_id) {
+  if ($service['version'] == 2 && !empty($response['openid.claimed_id']) && $response['openid.claimed_id'] != $claimed_id) {

$service['version'] specifies that the provider uses OpenID Authentication 2.0, i.e. not version 1.x.

Section 11.2 of the specification says:

If no Claimed Identifier is present in the response, the assertion is not about an identifier and the RP MUST NOT use the User-supplied Identifier associated with the current OpenID authentication transaction to identify the user. Extension information in the assertion MAY still be used.

Doesn't the patch introduce a violation of this?

Any updates here?

delegated id is busted for me too in d7 ... patch won't apply cleanly for me.

Moshe, I cannot reproduce that in D7. What exactly happens? If I copy the HTML code from http://www.tejasa.com/ and replace all occurrences of http://weitzman.myopenid.com with http://christian.schmidt.myopenid.com (my own OpenID identity), I can log in without problems.

#12: opendid.delegate.patch queued for re-testing.

Can someone confirm that this bug still exists in D7 and provide an updated description on how to reproduce it?

I can't reproduce this issue on alpha3, but on HEAD I'm having troubles when adding the delegated OpenID to the user account. MyOpenID, for example, reports:

It's likely that the site you are attempting to sign in to is running buggy software. It is known that some OpenID 2.0 implementations (especially certian versions of Drupal) do not work with delegated identifiers. In that case, please report this problem to the site you are trying to sign in to.

The regression since alpha3 was introduced in #218097: OpenID must use canonical ID when authenticating XRI i-names due to the use of the wrong namespace for <openid:Delegate> element.

I'm not familiar enough with OpenID, but this patch looks RTBC based on a pure code review.

@c960657, can you please include a test-case the steps to test this patch? E.g.

1) setup an open_id account like this
2) login to drupal like that
3) if fails like this

Apply the patch and notice it passes.

#23: openid-delegate-1.patch queued for re-testing.

Steps to reproduce:
1. Create an OpenID account, e.g. at MyOpenID.com. Assume your OpenID becomes http://username.myopenid.com
2. Create an HTML page containing a meta tag referencing the XRDS document of your, e.g.
<meta http-equiv="X-XRDS-Location" content="http://www.myopenid.com/xrds?username=username.myopenid.com" />
3. On your D7 site, log in with OpenID using the URL of the HTML page that you just created as the User-supplied Identifier.

Expected result:
The OpenID provider authenticates the user and redirects back to the Drupal site.

Actual result:
The OpenID provider complains, e.g. “myOpenID is not authorized to verify that "http://example.org/openid.html" is your identifier.”

#23: openid-delegate-1.patch queued for re-testing.

#23: openid-delegate-1.patch queued for re-testing.

looks like this might be a nice one for a novice

#23: openid-delegate-1.patch queued for re-testing.

decided to listen to myself and try a novice review...

code style looks good.

+++ modules/openid/openid.test	28 Mar 2010 22:25:46 -0000
@@ -40,58 +40,61 @@ class OpenIDFunctionalTest extends Drupa
-    $this->addIdentity(preg_replace('@^https?://@', '', $identity), 2, $identity);
+    $this->addIdentity(preg_replace('@^https?://@', '', $identity), 2, 'http://example.com/xrds', $identity);
+
+    $identity = url('openid-test/yadis/xrds/delegate', array('absolute' => TRUE));
+    $this->addIdentity(preg_replace('@^https?://@', '', $identity), 2, 'http://example.com/xrds-delegate', $identity);
 

Maybe a comment needed? I dont understand why there are two replacements... once for regular, and once for delegate? Actually, why does it seem to be adding many identities?

Ah, maybe these are all tests! (See, said I was a novice reviewer.)

67 critical left. Go review some!

still needs a functional review, someone to follow the steps in #28

Ah, sun did a code review in #24, I missed that.

#23: openid-delegate-1.patch queued for re-testing.

sun says rtbc based on code review in #24
I think the only thing needed if the bot says it is OK, is for a human to check the steps given in #28

I reproduced #28, it works. I got the expected result.

Committed to CVS HEAD. Thanks.