ubuntu-bengali-manual team mailing list archive
-
ubuntu-bengali-manual team
-
Mailing list archive
-
Message #05206
Re: [Bug 881019] Re: Lp login is broken after account merge
On Tue, May 29, 2012 at 2:13 AM, Monty Taylor <mordred@xxxxxxxxxxxx> 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) ?
--
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
References