ubuntu-bengali-manual team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

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

-- 
You received this bug notification because you are a member of Ubuntu
Bengali Manual, which is subscribed to LoCo Team Portal.
https://bugs.launchpad.net/bugs/881019

Title:
  Lp login is broken after account merge

Status in Canonical SSO provider:
  Confirmed
Status in Launchpad itself:
  Triaged
Status in LoCo Team Portal:
  Confirmed
Status in OpenStack Core Infrastructure:
  Confirmed
Status in Summit - The UDS Scheduler:
  Confirmed

Bug description:
  This looks like  bug 644824 (reopned?), though may also be bug 676964.
  In either case, openid are not matched correctly when the user logins
  in through SSO. Since both of these bugs were reported, the
  openididentifier table was created to store multiple ids for a user.
  Merge may not be dealing with the table correctly.

  There have also been many cases where the email address table (used to
  lookup Persons) has a different account from the account in the person
  table. This should be an impossibility. Maybe there should be a
  constraint, or column should be dropped from person, (or less likely
  emailaddress).

  Notes from gmb, 2011-11-24:

   - Dropping account from Person is prohibitively complex (see comments).
   - Running the following query:
         SELECT COUNT(*) FROM Person, EmailAddress WHERE
             EmailAddress.person = Person.id AND
             EmailAddress.account <> Person.account;
     tells us that there are currently two Persons in the production DB whose Person.account
     and EmailAddress.account don't match.

  --

  From the original question:
  One of our guys just recently merged two launchpad acounts into the account nati-ueno. The merge didn't go all the way through - there are times when the old openid gets referenced.

   https://login.launchpad.net/+id/BBze6nw
   https://login.launchpad.net/+id/X6dGn6P

  X6dGn6P is the correct one.

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-identity-provider/+bug/881019/+subscriptions