launchpad development|
⇤ ← Revision 1 as of 2010-02-18 18:14:16
Size: 1838
Comment:
|
Size: 2282
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 25: | Line 25: |
| '''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 |
|
| Line 27: | Line 30: |
| - We could revoke all write permissions on the AccountPassword table, as a safety net in case we leave behind any code that changes it | We could revoke all write permissions on the AccountPassword table, as a safety net in case we leave behind any code that changes it |
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
