User data doesn't get passed when signing on when OpenID 3.3.3 plugin is used

[Stephane Miller]

When a user logs in to a Wordpress blog, his or her details, such as LP username, name, and email do not seem to get passed. The problem occurs when using the OpenID 3.3.3 plugin with both Wordpress 2.9.2 and 3.0.1. When the user signs in, the usual "do you want to share this data with <site>" page appears, but only lists the user's team memberships and not any other data, such as name, that gets displayed (and used correctly) by blogs using the earlier OpenID 3.1 plugin. Accounts are autocreated for these users (if they don't already exist) but the account name and nickname are of the format login.ubuntu.com-id-<openid string>. In both cases, the version of the the other OpenID-related plugins are as follows:

OpenID launchpad - rev 19
OpenID teams - rev 26

When the above revisions of the teams and launchpad plugins are installed with OpenID 3.1, logins and new user creation function as expected.

[Brad Marshall (brad-marshall)]

I can confirm this also happens with Wordpress 3.2.1.

[Matthew Nuzum (newz)]

This is now fixed in version 1.0 of lp:wordpress-launchpad-integration (the latest revision). It requires OpenID 3.3.3 and should be installed along with version 1.0 of lp:wordpress-teams-integration (the latest revision).

[Brad Marshall (brad-marshall)]

I've setup a test blog based on Wordpress 3.2.1, with Openid 3.3.3 (downloaded from the wordpress plugin site), openid-launchpad 1.0 (bzr revno 23) and openid-teams 1.0 (bzr revno 29) and am getting weird behaviour.

I've setup a group that sets the users in it as Administrators, and that works ok the first time. Once we have one user created, every other user gets a blank page when they try to login and the following error message in the logs:

[Mon Aug 01 06:26:51 2011] [error] [client www.xxx.yyy.zzz] PHP Catchable fatal error: Object of class WP_Error could not be converted to string in /srv/wordpress3-farm/wordpress-3.x/wp-includes/formatting.php on line 2829, referer: https://blog-test.canonical.com/wp-login.php

Also, the user created by openid still appear lacking in detail - the username is login.ubuntu.com-id-<openid>, and there are no details like full name or email address. In the Launchpad settings I have Sync user data ticked, and we are using Ubuntu SSO production as the Launchpad server. The teams mapping has trust of any server.

Have I misconfigured this somewhere? Is there anything I'm missing in terms of software revisions etc for you to help us diagnose this problem? How can we progress diagnosing why this isn't working as advertised?

Thanks,
Brad

[Matthew Nuzum (newz)]

Brad, is it every other user? I think that error message means that it's trying to create an account for a user with the same e-mail address as an existing account. Check if the user you're trying to log in as has the same e-mail address of the admin account that you manually created when you configured the wordpress site.

[Matthew Nuzum (newz)]

Also, not all of the fixes take full effect unless you're using stagign SSO. We're waiting for that to land on production which will allow wordpress to get the full list of SREG details. You'll know it's working properly because when you hit SSO to authorize the account there will be a list of about four things it wants your permission to send.

[Brad Marshall (brad-marshall)]

> Brad, is it every other user? I think that error message means that it's trying to create an account for a user
> with the same e-mail address as an existing account. Check if the user you're trying to log in as has the same
> e-mail address of the admin account that you manually created when you configured the wordpress site.

This is likely whats happening, since the email address isn't being populated its conflicting, as they're all trying
use the empty string.

> Also, not all of the fixes take full effect unless you're using stagign SSO. We're waiting for that to land on
> production which will allow wordpress to get the full list of SREG details. You'll know it's working properly
> because when you hit SSO to authorize the account there will be a list of about four things it wants your
> permission to send.

Right, I hadn't seen anything about the need to use staging SSO so I had used production. When I switch to
staging SSO it works fine first time. So I guess we need to wait for it to roll out to production before we can
fix all the blogs.

Thanks,
Brad

[Brad Marshall (brad-marshall)]

This is looking good on lucid, although on a hardy server with wordpress (same versions as lucid), I see the following:

1) Go to https://blog.url/wp-login.php, click login
2) See the right details from the SSO server, click "Yes, sign me in"
3) Get redirected back to:
https://blog.url/wp-login.php?finish_openid=1&identity_url=https%3A%2F%2Flogin.staging.ubuntu.com%2F%2Bid%2FRFWw7nL&redirect_to=https://blog.url/wp-admin/&_wpnonce=<nonce>

Following a similar sequence on a lucid setup is fine, I get logged in with the correct credentials etc.

I suspect this may have something to do with dodgy data in the database, but there's no useful error messages to speak of.

Have you got any clues as to what might be going on here?