get or create lpuser via api

This is about creating a user for authentication, I think the foundations team needs to give this consideration. PersonSet should not be creating an Account, and I understand the Lp-foundations teams want to remove the table. This mechanism appears to by bypassing the email confirmation steps to ensure the user is legitimate.

Given that we are attacked by spammers every day, and one has proven to be partiulary adept at exploiting SSO and Launchpad to create identities, I think this feature are described is bad.

Hi Curtis,

The account should be created only if the identifier is valid (which can be checked via SSO) - that is, the user must already have an SSO account.

Michael's constraint (the user must already have an SSO account) sounds fine to me.

I talked about this with Francis last week. While I don't see a new spammer weakness with what Michael suggested, my opinion on the proposed (implemented?) solution is mixed for another reason.

AIUI, this is temporary, because we don't want to have to create LP users for software center purchasers in the future.

This is also a private API: only one celebrity should use it. We don't really even want to advertise it.

Because of this, I'm inclined to prefer using our private XMLRPC server, protected by IP address.

Francis' counterargument is "why have more than one way to expose APIs?"

That's a good question. However, I regard the REST webservice as a public resource. Because this is temporary *and* private, my gut wants this to not be around in the webservice.

That said, if we do already have an implementation of the webservice approach, I'll just quietly go along with it.

Fixed in stable r11112 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11112>.

Marking this as qa-bad - I've created a new user on login.staging.launchpad.net and then tried to access Launchpad (ie. there will not yet be an LP account), but it results in:

https://lp-oops.canonical.com/oops.py/?oopsid=1663S295

If I apply: http://pastebin.ubuntu.com/467028/ and then run:

$ bin/test -vv -m test_personset -t test_no_account_or_email

I can force a similar error:

{{{
  File "/home/michael/launchpad/lp-branches/598464-qa-fix/lib/lp/registry/model/person.py", line 2505, in getOrCreateByOpenID
Identifier
    return IPerson(account), db_updated
TypeError: ('Could not adapt', <Account 'Joe Bloggs' (Active account)>, <InterfaceClass lp.registry.interfaces.person.IPerson>)
}}}

But I'm not certain that the cause is correct. I can't see how it could be that the person doesn't exist when the adaption takes place, as it's all within a MasterStorePolicy block. I'll wait to hear from Gary (or someone with more insight), but if this is the case, then this would fix it: http://pastebin.ubuntu.com/467034/

The QA fix for this landed a few days ago on devel (r11209) which was merged into db-devel (r9570), but still waiting for staging to be updated to include this revision (r9565 at time of writing).

To QA:

1) Visit login.staging.launchpad.net and create a new account there (ie. an SSO only account)
2) After completing the verification and being logged in, visit staging.launchpad.net and ensure the oops is not triggered.

Fixed in stable r11209 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11209>.

QA'd the fix for the qa-bad using steps on comment 8 above.

I then QA'd the actual xmlrpc call as follows:

https://pastebin.canonical.com/35620/