New user name after LP login

django_openid_auth/auth.py line 71 checks the claimed id against existing ones in Django mapping user to openid account. The only thing I can figure is that we already had a user and openid mapping for him, but on this login we were given a different openid claimed id for the user than what we already had stored.

Consequently, it treated him as a new user, and since there was already a "netritious" django.auth.models.User account with that username, on line 104 is started adding an incrementing number to the username. This means there's likely also a "netritious1" user account and openid mapping, meaning this has happened at least twice now.

Without knowing what is in the loco.ubuntu.com app's database, it is a bit hard to know what the problem is. What Michael describes is how the "netritious2" user name would have appeared.

If you've got access to that database, running the following query should help determine what is going on:

  SELECT auth_user.username, django_openid_auth_useropenid.claimed_id
    FROM auth_user LEFT JOIN django_openid_auth_useropenid
      ON (auth_user.id = django_openid_auth_useropenid.user_id)
    WHERE auth_user.username LIKE 'netritious%';

There are two possibilities here: (a) there was an account called "netritious" in the database prior to using django_openid_auth with no OpenID identifier associated, or (b) someone else authenticated via OpenID and provided the "netritious" as a nickname first.

Hi,

loco_directory=> SELECT auth_user.username, django_openid_auth_useropenid.claimed_id
loco_directory-> FROM auth_user LEFT JOIN django_openid_auth_useropenid
loco_directory-> ON (auth_user.id = django_openid_auth_useropenid.user_id)
loco_directory-> WHERE auth_user.username LIKE 'netritious%';
  username | claimed_id
-------------+-----------------------------------------
 netritious |
 netritious2 | https://login.launchpad.net/+id/nzW4Efh
(2 rows)

Regards,
Paul

Okay, so it seems we're losing our claimed_id somehow.

Sorry for not getting back to you on this. For the first account, it is more likely to be a user with no associated UserOpenID record rather than a UserOpenID record with a blank claimed_id.

It might be useful to compare the auth_user.date_joined value for the different accounts. Was the unlinked account created before you were using django-openid-auth? Or are the creation times close together?

hi, the annoying point is that, inside http://summit.ubuntu.com/uds-o/ , I get marked as "You are not registered as attending." so I cannot interact. a.

We (=Canonical IS) have had a few tickets filed for this problem on
summit.ubuntu.com as well.

In each case when I look at the user's accounts, there is a Django
user "foo" and a user "foo2". User "foo" has no password set and no
matching row in django_openid_auth_useropenid, but user "foo2" does
have such a row and also no password set. Switching the usernames of
the Django accounts around fixes (or "fixes" ... but so far so good)
the symptoms for that particular user.

I have the same problem with the summit.ubuntu.com/uds-o site. I can't interact because it logs me in as chris.gagnon2 instead of chris.gagnon.

When I try to interact with the http://summit.ubuntu.com/uds-o/ website it tells me "You are not registered as attending."

I have the same problem with Loco.Ubuntu.com.

My LP nick is ~adnan.quaium (and I've only one LP account). When I logged in to LoCo Directory, I used that same LP account. And I could log in successfully. Then instead of showing my actual LP account/nick (in this case ~adnan.quaium), it shows a different account, which is ~adnan.quaium2. Also it has a hyper link to https://launchpad.net/~adnan.quaium2 , which doesn't exists!

I've tried several times, from several computer with several browser. Every time the result is same. I logged in with https://launchpad.net/~adnan.quaium, but after logging in it shows https://launchpad.net/~adnan.quaium2 instead of https://launchpad.net/~adnan.quaium.

Any solution to this?

We have the solution, but we are still working to try to get it deployed.

Hopefully the temporary solution will be run again in a few days.