• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Launchpad as an OpenID RP

Here are some notes on how we're going to change Launchpad to use login.launchpad.net (through OpenID) to authenticate users.

Later we might change Launchpad to use whatever OpenID provider is specified by the user, but that's out of scope here.

Migration plan

There's a chance that the rollout happens after a user started the registration process but before it's finished.

If that happens, once the roll out is finished the user will follow the link and try to complete the registration. At that time we need to either allow them to create a fully-functional account (i.e. one that works on login.launchpad.net as well) or tell them to start over on login.launchpad.net.

If during the rollout we split the auth/main databases for real, we won't be able to create a fully-functional account (as we won't have access to the auth DB, used by login.lp.net), so we'll need to change the logintoken view to direct users to login.lp.net.

However, if we do the real auth/main split on a subsequent rollout, we'd be able to create a fully-functional account with the existing code, not disrupting the user's experience.

The same would happen with someone trying to reset their password.

Notes on the main/auth split

The plan is to do the split but copy the EmailAddress and Account* tables over to the main db, later refactoring Launchpad to not use the Account* tables.

When Launchpad gets a positive assertion for an identity URL it hasn't seen before, it will just create a new Person/Account using the given email address, name (if any) and identity URL.

What to do about claiming of existing Person entries? We won't be able to do that in Launchpad because we'd need to set a password for the new account.

• I guess we'll have to ask them to register on login.lp.net first and when they get back to Launchpad we do the claiming automatically (in case they've registered with the email address linked to the existing Person), or later when they try claim the account while already logged in

Before the refactoring

• We could revoke all write permissions on the AccountPassword table, as a safety net in case we leave behind any code that changes it

After the refactoring

Things to consider before doing the split

Any code in Launchpad that changes the AccountPassword table is likely to represent a user being fooled into thinking their password was changed when in fact it was not -- remember the AccountPassword table copied to the main DB is not the one used when people login using login.lp.net. For that reason, we should do something about the following:

• Person.reactivate() must be changed to not set the password BR Account.activate() also sets the password BR Person.setPreferredEmail calls Account.activate() BR Person.createPersonAndEmail creates an Account and gives a password to it BR

Person.password should be removed