attempting to create a new account with an existing team email address at oopses

Bug #556680 reported by Michael Barnett on 2010-04-06
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Canonical SSO provider
Launchpad itself

Bug Description

I logged out of my existing account, went to, clicked "new account", filled in the form, got the email, followed the email link back to enter the name and password. Upon submitting this form i got an oops. All further attempts to log in as this user generated additional oopses.

Turns out the email address I used in the form (<email address hidden>) already existed in the database. (not sure if it is relevant, but it had no account associated with it, and the user it was attached to had no account.) Upon investigation with ricardokirkner, we determined that there are additional constraints on the production database than are in the model.

ADDENDUM: The email address belongs to a team, and teams cannot be converted to users.

Michael Barnett (mbarnett) wrote :

Original Ooops: Oops-Id: 1557carambola24
Oops from trying to log in after: Oops-Id: 1557canistel15

Changed in canonical-identity-provider:
milestone: none → 2.5.0
Changed in canonical-identity-provider:
milestone: 2.5.0 → 2.6.0
Changed in canonical-identity-provider:
assignee: nobody → Stuart Metcalfe (stuartmetcalfe)
status: New → Incomplete
Anthony Lenton (elachuni) wrote :

We're no longer able to restrict account creation so that emails related to team Persons from Launchpad aren't allowed to be used to create new Accounts, because we're not receiving updates for the emailaddress table.

Since we can't enforce this for every email address, the right thing to do is to not enforce it for *any* address, and let Launchpad refuse an account when it tries to sign in, it it notices it's related to a team Person.

So, we should a) check if an emailaddress already exists in the system when creating an account; then allow Emailaddresses that have a Person but not an Account create an Account, and b) ignore the Person's data when reporting sreg information to an RP if the Person is actually a team.

Changed in canonical-identity-provider:
milestone: 2.6.0 → 2.7.0
David Owen (dsowen) on 2010-07-28
tags: added: isd-logging-sprint
Danny Tamez (zematynnad) on 2010-08-03
Changed in canonical-isd-qa:
milestone: none → canonical-identity-provider+2.7.0
Changed in canonical-identity-provider:
milestone: 2.7.0 → none
Changed in canonical-identity-provider:
milestone: none → 2.8.0
Julien Funk (jaboing) on 2010-08-06
Changed in canonical-isd-qa:
milestone: canonical-identity-provider+2.7.0 → canonical-identity-provider+2.8.0

Moving to 2.10.0 so we can follow up with LP over the Maverick release when things are a little more sane

Changed in canonical-identity-provider:
milestone: 2.8.0 → 2.10.0
Julien Funk (jaboing) on 2010-09-03
Changed in canonical-isd-qa:
milestone: canonical-identity-provider+2.8.0 → canonical-identity-provider+2.10.0
Changed in canonical-identity-provider:
importance: Undecided → High
milestone: 2.10.0 → not-release-dependent
Gary Poster (gary) wrote :

Yesterday, I spoke with Curtis Hovey about this, and in particular the parts of it that relate to Launchpad. Here's my understanding.

I largely agree with Anthony's comment (#2 above). To be precise:

1) CIP should not try to block any emails being assigned to SSO accounts.
2) Launchpad should be in charge of disallowing any SSO account from being associated with a team. As corollaries:
   * A new-to-LP SSO account that has an SSO preferred email address that is the same as a team's email address may not be associated with the team. (The workflow of this can be a separate discussion.)
   * An existing SSO account that is already associated with a (non-team) person but which has a SSO preferred email address that corresponds with a team (via changes in SSO or LP) will simply have its email address ignored: no errors or warnings should be raised.

Therefore, to address this bug, LP needs to verify that it enforces these constraints. CIP can definitely stop trying to block emails at that point. If the blocking is pointless now, maybe it can even be removed sooner, but that's more for ISD to determine, I think.

Changed in launchpad-foundations:
status: New → Triaged
importance: Undecided → High
Curtis Hovey (sinzui) on 2012-01-16
summary: - attempting to create a new account with an existing email address at
- oopses after you follow the email link back to create
- the name/password
+ attempting to create a new account with an existing team email address
+ at oopses
description: updated
Curtis Hovey (sinzui) on 2012-01-19
tags: added: openid
Changed in launchpad:
importance: High → Critical
tags: added: oops
Download full text (4.5 KiB)

After some discussion with Curtis, the correct algorithm is probably thus:

    if openid is known:
        log in as openid's person
        if email is unknown:
            link email to openid's person
        elif email is owned by some other person or a team:
            warn user that things are confused
        if email and belongs to a person:
             log in as email's person
             link openid to email's person
        elif email belongs to a team:
             reject login
             create new person with email and openid

    if person is not active:
       # Do stuff, discussed below.

The main difference from the current implementation is the "warn user
that things are confused" bit. Currently we steal the email address from
its rightful owner and forcibly associate it with the OpenID
identifier's person. This is rather harmful if it steals a team's
contact address (changing how notifications work), a person's preferred
email address (making the person inactive), or even a person's last
remaining email address (making them largely unidentifiable and
difficult to recover).

The proposal puts a mismatch between identifier and email person into
one of four categories:

 - The identifier has no person. The email address is associated with a
   team. Launchpad explains that this is impossible, and rejects the
   login attempt.

 - The identifier has no person. The email address is associated with a
   person. Launchpad links the identifier to the email address' person.

 - The identifier has a person. The email address has a different person
   or a team. Launchpad displays a warning with a guide to resolution.

 - The identifier has a person. The email address has no person.
   Launchpad links the email address to the identifier's person.

Inactive profiles

There is also the issue of unactivated, deactivated and suspended
profiles. All can be reached in the login process by having a
corresponding address in SSO, and deactivated/suspended can be reached
by OpenID identifier.

  - Unactivated profiles happen when eg. a Debian developer referenced
    in a package upload logs into Launchpad for the first time. They
    have an existing person without a preferredemail or active account.
    Given that we trust SSO to verify email addresses and we know the
    address is associated with this profile, we could continue to just
    activate the account and set the login address as preferred.

  - Deactivated profiles have no preferredemail, and currently get
    immediately reactivated with the login email address. While we could
    continue doing this, it upsets users as it looks as if the profile
    never went away. It's also a problem in the proposed algorithm,
    since we don't always have a usable email address (the login address
    may be occupied by a team).

  - Suspended profiles have no preferredemail, and login attempts are
    rejected. This probably doesn't change.

Since we don't always have a confirmed email address to set as
preferred, we can't always activate a profile automatically. Combined
with the confused email address warning, it looks like we have to ad...


Changed in launchpad:
status: Triaged → Confirmed
Changed in canonical-identity-provider:
status: Incomplete → Confirmed
Curtis Hovey (sinzui) on 2012-07-22
Changed in launchpad:
status: Confirmed → Triaged
Changed in canonical-identity-provider:
assignee: Stuart Metcalfe (stuartmetcalfe) → nobody
milestone: not-release-dependent → none
William Grant (wgrant) on 2012-10-04
Changed in launchpad:
importance: Critical → High
tags: removed: oops
William Grant (wgrant) on 2014-11-23
no longer affects: ubuntu
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers