Lp login is broken after account merge

About dropping columns. It would seem at first glance that the person column should be dropped from emailaddress to ensure that person are looked up via account. This breaks team and unactivated profiles which do not have accounts. It is possible to drop account from person...it is rarely used and can be gotten via the email address or query against account.

The other option is to drip account from email address so the table is restored to the schema before the SSO mess.

I am wondering if bug #884249 is this problem as well. Through conversation on IRC during UDS, the op stated that he had 'multiple' accounts merged. I am wondering if it is possible that his attempt to login is sending an old openid. The issue for this user was not fixed with the update to django-openid-auth as we had expected it to be. I believe Michael Hall confirmed that the openid url that we were getting didn't match the url reported on his LP account page.

Oh that bug does looks like the same issue.

When users merge Lp profiles, the OpenID Identifiers are copied too. The assumption is that the user has two Ubuntu SSO identities that map to one profile in Lp. I have seen a lot of madness with criss-crossed email addresses -- SSO and Lp can have different email address associated with the OpenID identifier.

I've had a branch going for the last week or so, trying to drop account from Person. It's been an abject failure, so I'm ditching it and going back to the drawing board.

The problems are:

 1. Although Person.account isn't used all that much, it turns out that its existence is relied on by other things just enough to cause a great number of problems when it's taken away.
 2. Removing Person.account (or replacing it with a lookup against EmailAddress.account) leads to a race condition when merging accounts and causes OpenID identifiers essentially to become orphaned. Since the point of this bug is that OpenID should be fixed, not broken further, I figured that this was a Bad Thing.

Item 2 on this list is work-around-able, but the workaround is a kludge and makes fairly complex code even worse.

So, I'm scrapping that branch and going back to the lowest level of the problem: inconsistent data in the DB. Whether that will be any easier to solve, I don't know.

Hi gmb.

I am very sorry for you. Maybe fixing bug 770107 (which is a feature requiring collaboration between ~launchpad and ~isd) will alleviate the issue. I think the root cause of Lp's identity issues is the fact that Lp and SSO have different sets of addresses.

Hi Curtis,

I agree. We can put a DB constraint in place to prevent the data problem from arising (though there's a chance we might see some OOPSes in doing so - which might not necessarily be a bad thing).

I'll move this bug back to Triaged for now and file a separate one for the DB constraint. It's probably worth kicking this problem up to Francis and Robert so that they can negotiate with ISD to get some collaborative eyeballs on the problem.

Graham, do you perhaps have a list of the things that depend on
account? Might be useful for planning future lean-ups in this area.

On 24 November 2011 20:27, Robert Collins <email address hidden> wrote:
> Graham, do you perhaps have a list of the things that depend on
> account? Might be useful for planning future lean-ups in this area.

I don't, but I'll happily put one together.

+1 to add a constraint to the DB. I would rather see an oops with valid data than dealing with corrupt data.

I have branches partly landed to address the person/account consistency issue by fixing bug #629172 (dropping EmailAddress.account).

The problem here is really OpenStack's gerrit plugin thing for LP team integration. It appears to have a cronjob that pulls all members of a Launchpad team, screenscrapes their delegated identity from Person:+index, and adds a permission for that identifier. This doesn't work well for LP accounts with multiple identifiers, usually from a person or SSO account merge, as the delegated identifier may not match the identity of the primary SSO account.

We probably want to expose an API in Launchpad to allow retrieval of team information for a given OpenID identifier, but the correct thing for gerrit to do in the current environment is use the team information from the OpenID response.

It is on our todo list to use the team information from the OpenID
response directly in gerrit. Once we do that, I can stop having to do
the batch create of user accoutns in gerrit. However, that means a Java
patch to Gerrit core, so it's probably not going to get done tomorrow. :)

In terms of API additions, team info for a given OpenID identifier would
not be useful - what I need is to get via the API is the OpenID
identifier for a given user. If I could get that, I could stop
screen-scraping.

Thanks!
Monty

On 01/19/2012 02:33 PM, William Grant wrote:
> The problem here is really OpenStack's gerrit plugin thing for LP team
> integration. It appears to have a cronjob that pulls all members of a
> Launchpad team, screenscrapes their delegated identity from
> Person:+index, and adds a permission for that identifier. This doesn't
> work well for LP accounts with multiple identifiers, usually from a
> person or SSO account merge, as the delegated identifier may not match
> the identity of the primary SSO account.
>
> We probably want to expose an API in Launchpad to allow retrieval of
> team information for a given OpenID identifier, but the correct thing
> for gerrit to do in the current environment is use the team information
> from the OpenID response.
>

On 20/01/12 00:52, Monty Taylor wrote:
> It is on our todo list to use the team information from the OpenID
> response directly in gerrit. Once we do that, I can stop having to do
> the batch create of user accoutns in gerrit. However, that means a Java
> patch to Gerrit core, so it's probably not going to get done tomorrow. :)
>
> In terms of API additions, team info for a given OpenID identifier would
> not be useful - what I need is to get via the API is the OpenID
> identifier for a given user. If I could get that, I could stop
> screen-scraping.

A user doesn't have a unique OpenID identifier. They can have multiple
due to account merges, and eventually several from different providers.
We could possibly allow them to select the primary identity, but really
you should be looking things at authentication-time, not before.

On 01/20/2012 09:22 AM, William Grant wrote:
> On 20/01/12 00:52, Monty Taylor wrote:
>> It is on our todo list to use the team information from the OpenID
>> response directly in gerrit. Once we do that, I can stop having to do
>> the batch create of user accoutns in gerrit. However, that means a Java
>> patch to Gerrit core, so it's probably not going to get done tomorrow. :)
>>
>> In terms of API additions, team info for a given OpenID identifier would
>> not be useful - what I need is to get via the API is the OpenID
>> identifier for a given user. If I could get that, I could stop
>> screen-scraping.
>
> A user doesn't have a unique OpenID identifier. They can have multiple
> due to account merges, and eventually several from different providers.
> We could possibly allow them to select the primary identity, but really
> you should be looking things at authentication-time, not before.

I can't just look at things at authentication-time, because gerrit has
multiple different access mechanisms. One of those is through the web,
another is ssh. Also, gerrit doesn't support Launchpad's group extension
yet, so the import is the best I've got.

That having been said, it may be the case that a user has more than one
identity in the current system as a happenstance, but is that really the
design? You're telling me that it's on purpose that there is no way to
map the Launchpad User ID "mordred" to the openid identifier that will
be returned if I try to log in via OpenID to that account? I'd love to
hear why that's an intended design and not either a bug or a
happenstance of how account merges got implemented. Up until this point,
everyone else I've spoken to seems to think that the discrepancy is a bug.

On 20/01/12 14:15, Monty Taylor wrote:
> On 01/20/2012 09:22 AM, William Grant wrote:
>> On 20/01/12 00:52, Monty Taylor wrote:
>>> It is on our todo list to use the team information from the OpenID
>>> response directly in gerrit. Once we do that, I can stop having to do
>>> the batch create of user accoutns in gerrit. However, that means a Java
>>> patch to Gerrit core, so it's probably not going to get done tomorrow. :)
>>>
>>> In terms of API additions, team info for a given OpenID identifier would
>>> not be useful - what I need is to get via the API is the OpenID
>>> identifier for a given user. If I could get that, I could stop
>>> screen-scraping.
>>
>> A user doesn't have a unique OpenID identifier. They can have multiple
>> due to account merges, and eventually several from different providers.
>> We could possibly allow them to select the primary identity, but really
>> you should be looking things at authentication-time, not before.
>
> I can't just look at things at authentication-time, because gerrit has
> multiple different access mechanisms. One of those is through the web,
> another is ssh. Also, gerrit doesn't support Launchpad's group extension
> yet, so the import is the best I've got.

But presumably the OpenID identifier isn't relevant to SSH :)

> That having been said, it may be the case that a user has more than one
> identity in the current system as a happenstance, but is that really the
> design? You're telling me that it's on purpose that there is no way to
> map the Launchpad User ID "mordred" to the openid identifier that will
> be returned if I try to log in via OpenID to that account? I'd love to
> hear why that's an intended design and not either a bug or a
> happenstance of how account merges got implemented. Up until this point,
> everyone else I've spoken to seems to think that the discrepancy is a bug.

OpenID identifiers are very similar to email addresses. A user may have
several that they use in different places (in no small part because of
the proliferation of awkward providers-but-not-true-consumers like
Launchpad), and Launchpad needs to be able to identify the user by all
of them.

Now, Launchpad is still restricted to a single provider. This means that
multiple identifiers don't occur except when people mistakenly create
multiple SSO accounts, log into Launchpad with both, and merge the two
resulting Launchpad profiles. And it's not clear which identifier should
win when merging profiles, so we keep both linked, letting both SSO
accounts log into the one profile.

SSO can't really sensibly do account merging. That would cause one of
the identifiers to disappear, locking the user out of any accounts on
consuming services that only know about the duplicate identifier. In a
lot of cases the user probably hasn't used the second SSO account for
anything notable, and really wants to entirely destroy all trace of
duplicate account from both SSO and Launchpad.

But there's presently no way for users to manage their identifiers. If
there was, we could allow them to remove the unwanted duplicates, and
select their primary identity -- just as we do with email addresses.
This hasn't been done largely becaus...

On 01/20/2012 02:53 PM, William Grant wrote:
> On 20/01/12 14:15, Monty Taylor wrote:
>> On 01/20/2012 09:22 AM, William Grant wrote:
>>> On 20/01/12 00:52, Monty Taylor wrote:
>>>> It is on our todo list to use the team information from the OpenID
>>>> response directly in gerrit. Once we do that, I can stop having to do
>>>> the batch create of user accoutns in gerrit. However, that means a Java
>>>> patch to Gerrit core, so it's probably not going to get done tomorrow. :)
>>>>
>>>> In terms of API additions, team info for a given OpenID identifier would
>>>> not be useful - what I need is to get via the API is the OpenID
>>>> identifier for a given user. If I could get that, I could stop
>>>> screen-scraping.
>>>
>>> A user doesn't have a unique OpenID identifier. They can have multiple
>>> due to account merges, and eventually several from different providers.
>>> We could possibly allow them to select the primary identity, but really
>>> you should be looking things at authentication-time, not before.
>>
>> I can't just look at things at authentication-time, because gerrit has
>> multiple different access mechanisms. One of those is through the web,
>> another is ssh. Also, gerrit doesn't support Launchpad's group extension
>> yet, so the import is the best I've got.
>
> But presumably the OpenID identifier isn't relevant to SSH :)

Nope - but I need to get the ssh key from the launchpad account, and
once I've created that account, I need to be able to map their login
once they've logged in through the web. :) (It's a REALLY fun problem
domain, I promise)

>> That having been said, it may be the case that a user has more than one
>> identity in the current system as a happenstance, but is that really the
>> design? You're telling me that it's on purpose that there is no way to
>> map the Launchpad User ID "mordred" to the openid identifier that will
>> be returned if I try to log in via OpenID to that account? I'd love to
>> hear why that's an intended design and not either a bug or a
>> happenstance of how account merges got implemented. Up until this point,
>> everyone else I've spoken to seems to think that the discrepancy is a bug.
>
> OpenID identifiers are very similar to email addresses. A user may have
> several that they use in different places (in no small part because of
> the proliferation of awkward providers-but-not-true-consumers like
> Launchpad), and Launchpad needs to be able to identify the user by all
> of them.
>
> Now, Launchpad is still restricted to a single provider. This means that
> multiple identifiers don't occur except when people mistakenly create
> multiple SSO accounts, log into Launchpad with both, and merge the two
> resulting Launchpad profiles. And it's not clear which identifier should
> win when merging profiles, so we keep both linked, letting both SSO
> accounts log into the one profile.
>
> SSO can't really sensibly do account merging. That would cause one of
> the identifiers to disappear, locking the user out of any accounts on
> consuming services that only know about the duplicate identifier. In a
> lot of cases the user probably hasn't used the second SSO account for
> anything notabl...

On 20/01/12 15:04, Monty Taylor wrote:
> Ugh. Ok - that makes sense, although it makes me want to cry a little
> bit.

You're telling me :(

> I suppose a launchpad api patch to allow getting the OpenID identity
> which will show up on <https://launchpad.net/~someperson> will take
> about as much time as a patch to gerrit to support group extension?

Would it help to be able to retrieve all the identifiers linked to a
person? That's relatively simple and inoffensive. I guess it might not
work if gerrit likes only a single identifier per user, though.

> /me cries in the corner

That's probably the correct course of action for all of us :/

William Grant (wgrant) wrote on 2012-01-19:

> Would it help to be able to retrieve all the identifiers linked to a
> person? That's relatively simple and inoffensive. I guess it might not
> work if gerrit likes only a single identifier per user, though.

That sounds useful, and gerrit ostensibly supports multiple openid identifiers per-user, so it _should_ work. I don't have a good way of testing that right now since I don't have access to a "merged" account.

This seems to be causing issues with Summit. A users personal schedule is given to them when they are logged in, however it seems as though not everyone is being logged in properly. This could create major issues as sometimes users are scheduled for private business meetings. These meetings only show up on their personal schedule. A user may miss one of these meetings, which would not be a good idea.

A slight comment on this

  Now, Launchpad is still restricted to a single provider. This means that
  multiple identifiers don't occur except when people mistakenly create
  multiple SSO accounts, log into Launchpad with both, and merge the two
  resulting Launchpad profiles. And it's not clear which identifier should
  win when merging profiles, so we keep both linked, letting both SSO
  accounts log into the one profile.

Actually, SSO does merge one account *into* another, effectively discarding the "source" account (the user will still be able to log in with the old email address, but only because that address is added to the "target" account). Therefore, the only valid openid should be target accounts one (ie, it is possible to know which openid the user will have after the merge).

Ah, but you were talking about launchpad profiles.... so that's an entirely different issue I guess

In order to correctly triage this bug in canonical-identity-provider, can we confirm this is still happening?

thanks,
Ricardo

Ricardo, I don't know if people who's accounts are being merged currently are being effected, but there are still users AFAIK who have previously merged accounts and are having problems still.

It's still happening. It's not clear whether c-i-p can do much, apart from working out why so many people get duplicate SSO accounts.

we have on average 2 people a week with this issue still on OpenStack.

Is bug #982887 the same as well?

I suspect I'm also encountering this when I try to log in to http://summit.ubuntu.com/uds-q/
I receive a message "The username (lloydde) with which you tried to log in is already in use for a different account."

I'm also from OpenStack, and also have a merged account.

Still seeing this issue, trying to use summit.linaro.org. Any clues on what's gone/going wrong?

So, this looks to be a problem due to different things being called "account merge".

On one side we have

- SSO account merge
- LP account merge

and they do different things.

I will speak only about the SSO one as that's the one I know :)

When two SSO accounts get merged, the source account will get deactivated, and all of it's associated emails will get added to the target account (thus, the source account's openid will no longer be valid).

In all reported cases we found multiple SSO accounts linked to the same LP account. This possibly caused the wrong openid to be setup at the summit sites. This in turn was probably caused by LP merging the accounts without telling SSO about it, thus getting the SSO side of things out of sync.

The way to properly fix this is by having LP notify SSO by some (yet non-existing means) when two accounts need to be merged so SSO can merge their corresponding parts too.

That would tie Launchpad and SSO together more tightly in yet another way. It's not a solution.

As a workaround for Openstack at least if there was a way of listing all OpenIDs for a give account (whether it is hidden in the user profile page or via. launchpadlib) we can easily associate them in our applications. It would make us very happy people and I suspect it would not be a lot of work to implement.

Are we going to see any progress on this please?

I'm now on-site at Linaro Connect and effectively unable to use Summit. One of the sessions that I'm meant to be running has been scheduled for a day I'm not here, and I know there are private meetings this week where I'm expected to attend but I currently have no visibility of those at all. This is getting ludicrous. I appreciate from comments above that this is not an easy bug to fix, but that doesn't help me get my work done this week. Are there any workarounds that anyone can suggest? Would it be easiest if I just deleted and recreated all Launchpad state from scratch?

This isn't really a bug in Launchpad or SSO. While we'll hopefully eventually add facilities to manage OpenID identifier associations, the multiple associations are only a problem when the consumer is buggy! Any changes to Launchpad would simply serve to work around the bugs in the consumers. The only consumers I know to be buggy in this respect are Summit and OpenStack's gerrit -- they're trying to do the mapping the wrong way.

Steve, you've somehow created four separate SSO accounts, all associated with your Launchpad account. If you file a support request at https://answers.launchpad.net/launchpad/+addquestion we can get some of them cleaned up to work around the Summit incompatibility.

With respect to the OpenStack Gerrit, it's not that the consumer is buggy, it's that since we're trying to _integrate_ with Launchpad, we need to know the _Launchpad_ user of the person who is authenticating to us. It's not enough to just know be given an opaque identifier, we need to know the Launchpad user ID of that person so that we know what groups they are a member of, etc. If we just wanted to use an opaque OpenID provider, we could have used any number of other ones. The value in using Launchpad's OpenID provider is that we can integrate our tools and processes with Launchpad.

William, a while ago you suggested an API call that would allow us to query all of the identifiers for a given Launchpad account? I believe we can work around the problem if that's added. Do you still think that would be feasible?

On 28/05/12 12:27, James E. Blair wrote:
> With respect to the OpenStack Gerrit, it's not that the consumer is
> buggy, it's that since we're trying to _integrate_ with Launchpad, we
> need to know the _Launchpad_ user of the person who is authenticating to
> us. It's not enough to just know be given an opaque identifier, we need
> to know the Launchpad user ID of that person so that we know what groups
> they are a member of, etc. If we just wanted to use an opaque OpenID
> provider, we could have used any number of other ones. The value in
> using Launchpad's OpenID provider is that we can integrate our tools and
> processes with Launchpad.
>
> William, a while ago you suggested an API call that would allow us to
> query all of the identifiers for a given Launchpad account? I believe
> we can work around the problem if that's added. Do you still think that
> would be feasible?

After discussion with Summit developers this morning, I'm adding an API
to go the other way: given an OpenID identifier, you'll be able to
easily ask for the corresponding Launchpad account. That's bug #1005330.

Can you alter the gerrit login process enough to use that API? Adding a
second API for account -> identifiers would work for you, and is doable,
but it doesn't make a huge amount of sense so it would be nice to avoid it.

On 05/27/2012 10:43 PM, William Grant wrote:
> On 28/05/12 12:27, James E. Blair wrote:
>> With respect to the OpenStack Gerrit, it's not that the consumer is
>> buggy, it's that since we're trying to _integrate_ with Launchpad, we
>> need to know the _Launchpad_ user of the person who is authenticating to
>> us. It's not enough to just know be given an opaque identifier, we need
>> to know the Launchpad user ID of that person so that we know what groups
>> they are a member of, etc. If we just wanted to use an opaque OpenID
>> provider, we could have used any number of other ones. The value in
>> using Launchpad's OpenID provider is that we can integrate our tools and
>> processes with Launchpad.
>>
>> William, a while ago you suggested an API call that would allow us to
>> query all of the identifiers for a given Launchpad account? I believe
>> we can work around the problem if that's added. Do you still think that
>> would be feasible?
>
> After discussion with Summit developers this morning, I'm adding an API
> to go the other way: given an OpenID identifier, you'll be able to
> easily ask for the corresponding Launchpad account. That's bug #1005330.
>
> Can you alter the gerrit login process enough to use that API? Adding a
> second API for account -> identifiers would work for you, and is doable,
> but it doesn't make a huge amount of sense so it would be nice to avoid it.

We can update our use sync script to use this, but I don't know that the
mapping in that direction will immediately solve the problem. Just so
you have the full context, the way it works is that we have a script
will pulls user information from launchpad api (with an additional curl
call given the launchpad user id to their user page to find their openid
id) We do that because the web is not the only way a person logs in to
gerrit - we also have ssh-based interactions because of git pushes and
pulls. That means we need discreet user accounts so that there will be a
place to attach an ssh key (which we also grab from launchpad if there
is one for ease of use for our users)

Now, I suppose we could have an additional script which looks through
our database for the list of openids and then does the reverse calls to
launchpad to map those to launchpad user ids, and then tries to do the
merging on our side. Just so that you are aware, I expect that to run
about 3k API calls per 15 minutes against launchpad.

Andrew has taken over the sync script though, so I'm including him here
just to make sure I'm not mis-representing things.

Thanks!
Monty

I think you need to change your integration logic :)

Define the LP ids you want to have access however you want to do it;
when an openid login occurs, call the LP mapping IP with the openid
identifier that was used to login, and that will give you their LP
userid (if it exists).

-> no batch scripting needed at all.

On 05/28/2012 12:42 AM, Robert Collins wrote:
> I think you need to change your integration logic :)

Heh. It always seems that way at first glance.

> Define the LP ids you want to have access however you want to do it;
> when an openid login occurs, call the LP mapping IP with the openid
> identifier that was used to login, and that will give you their LP
> userid (if it exists).
>
> -> no batch scripting needed at all.

Well, we'll still have to batch-operate to get the set of LP ids and
their group membership and their SSH keys so that ssh-based auth
continues to work (or stops working if we remove someone from a group
and they don't happen to log in via the web after that). So unless you
want to provide an LDAP interface to launchpad auth ... :) we'll have to
keep doing that. Since we're doing that - just pre-grabbing the openid
information makes way more sense than attempting to inject an api call
into the gerrit openid chain.

Since we're presenting a unified system with Launchpad, Gerrit, and our other tools, a user's first interaction with Gerrit may well be over SSH. This works because we are able to pre-populate Gerrit's database using the LP account -> OpenID mapping. Having an API call to do that correctly would be very helpful and make this work for everyone. Having a user log in to Gerrit just to "register" when everything should be automatic isn't a great UX.

So my strong preference would be a user->identifier API call. If that's unworkable, I believe we can use an identifier->user API call to straighten out our database after the fact for the users who show up with an otherwise unknown ID. ("Gerrit doesn't work for you? Wait 15 minutes and try again.")

On Tue, May 29, 2012 at 2:13 AM, Monty Taylor <email address hidden> wrote:
> On 05/28/2012 12:42 AM, Robert Collins wrote:
>> I think you need to change your integration logic :)
>
> Heh. It always seems that way at first glance.
>
>> Define the LP ids you want to have access however you want to do it;
>> when an openid login occurs, call the LP mapping IP with the openid
>> identifier that was used to login, and that will give you their LP
>> userid (if it exists).
>>
>> -> no batch scripting needed at all.
>
> Well, we'll still have to batch-operate to get the set of LP ids and
> their group membership and their SSH keys so that ssh-based auth

From this I infer you are using openssh or similar? There is e.g.
conch which can talk to LP directly with only a modicum of effort, and
do real-time access for keys (and group checks).

Or, I'm sure its around somewhere, you could use the LP PAM module. I
may be misremembering the existence of this, though I'm sure someone
did write one.

> continues to work (or stops working if we remove someone from a group
> and they don't happen to log in via the web after that). So unless you
> want to provide an LDAP interface to launchpad auth ... :) we'll have to
> keep doing that. Since we're doing that - just pre-grabbing the openid
> information makes way more sense than attempting to inject an api call
> into the gerrit openid chain.

Ok, so that seems like you'd have a user for getting the N-openid
identifiers list. Note that it really is an arbitrary length list:
users can have as many openid identifiers as they want. Does gerrit
support such a mapping (N openid identifiers, one user) ?

On Tue, May 29, 2012 at 2:50 AM, James E. Blair <email address hidden> wrote:
> Since we're presenting a unified system with Launchpad, Gerrit, and our
> other tools, a user's first interaction with Gerrit may well be over
> SSH.  This works because we are able to pre-populate Gerrit's database
> using the LP account -> OpenID mapping.  Having an API call to do that
> correctly would be very helpful and make this work for everyone.  Having
> a user log in to Gerrit just to "register" when everything should be
> automatic isn't a great UX.

You can take the userid in the ssh challenge and map via the existing
sshkeys API to determine their SSH key in realtime. Depending on the
SSH server you are using, this may be more or less easy though.

bzr+ssh://bazaar.launchpad.net does precisely this (though it uses a
predecessor of the current LP API which isn't externally exposed).

-Rob

I do not think there is any work left for the Launchpad team to do with this bug. This issue from Lp's code perspective is either fixed or a low priority request to add additional (undefined) APIs that can be used to integrate with Lp.

I don't agree with that statement. Nothing has changed; we're unable to use Launchpad as an OpenID provider in any meaningful way. I think the problem has been fairly well articulated, as well as two possible solutions you could implement that would work with Launchpad's multiple-id-per-user scheme.

To answer Robert's question directly, yes, Gerrit supports multiple OpenID providers per user. If I had a way to know what those were, I could use them. So a user -> N*OpenID_identifiers mapping would be ideal.

I reported this bug to address cases where merging profiles causes the use to login under a different identity because Launchpad could bot resolve email addresses. Those model changes have landed and this is no longer an issue. User can log in again and they can work. As the reporter of this bug, I and satisfied.

There is a secondary issue where external groups cannot reconcile users with multiple openid identifiers. This users can log in, but secondary services cannot identify the user. This is a feature request, and API changes have been made to accommodate the issue, but it is not clear what other new features are needed to support this use case.

Hitting this bug . "The username (khadgaray) with which you tried to log in is already in use for a different account." .

Ritesh, I need your email address that you use to login to SSO please.

@Chris

  <email address hidden> is listed as my preferred email. My login works now, after I amasked for "team membership" listed as "canonical" .

Thank you.

Any update on this ? we are getting a lot of reports about it.

I can no longer log in to the loco side:

The username (marcus.moeller) with which you tried to log in is already in use for a different account.

after changing the email address of one email in a merged account. This is a real restriction, because it limits my LoCo work.

@adnane from Launchpad point of view we're currently working on bugs marked critical and will then move onto bugs marked high.

i have the same issue. When I created launchpad account I had <email address hidden> and I changed to <email address hidden>. Then the problem began.

Vasilis, what site are you having trouble logging into?

I at least cannot login to http://loco.ubuntu.com/openid/complete

Chris, here is the link: http://loco.ubuntu.com/events/ubuntu-greek-users/2330-fosscomm-2013-ubuntu-gr/

If I try to delete my account and sign it again, does it fix this?

Lp accounts/profiles cannot be deleted. They can only be deactivated. Accounts/profiles are silently reactivate when you login (because Lp wrongly assumes that Ubuntu SSO knows everything about the users Lp activity).

I've having the same issue. When I log to loco.ubuntu.com it says :

The username with which you tried to log in is already in use for a different account.

Today I noticed this. After so many days after the email change, I decided to log in with my old email. Guess what, there was another profile with the same details such as launchpad id and karma. I didn't make any other account but the launchpad thinks I did one. Check this page and enter your old login mail to see for yourself.

For example I can log in now to http://loco.ubuntu.com/ with the old mail (hotmail) but not with new one (gmail).

Also I have two Ubuntu one acoounts as https://login.ubuntu.com/+emails says.

"An Ubuntu One account already exists with this email."

Is there any update on this issue?

So far, when I change my nickname in launchpad I am then able to sign in to the LoCo Portal. I however can't seem to update details on the LoCo Team page where I am admin.

If the LoCo Portal is still using Launchpad usernames to identify users, you'll need to contact the people who manage the Portal and get them to fix your Portal account.

I have merge two launchpad accounts in the past. Checking on a fix for this 2011 bug.

Currently getting this error when trying to log in to UOD November 2015:
The username with which you tried to log in is already in use for a different account.

On 05/11/15 00:20, komputes wrote:
> I have merge two launchpad accounts in the past. Checking on a fix for
> this 2011 bug.
>
> Currently getting this error when trying to log in to UOD November 2015:
> The username with which you tried to log in is already in use for a different account.

You need to contact the admin of the website that gave you that error.
It's not a Launchpad issue.