launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, May 25, 2011 at 12:18 AM, Jeroen Vermeulen <jtv@xxxxxxxxxxxxx> wrote:
> The former is the only part I'm asking about: a celebrity that can own
> things, be the author of messages etc.  Not an actor in the strict sense of
> the word, although it may be seen as one from the user's point of view.
>
> We've been creating these persons irregularly and ad-hoc, with the sheer
> inconvenience as the main moderating factor — plus nowadays the ban on new
> sample data, and possibly fine-grained rollouts requiring a new celebrity to
> be created on the production / staging / qastaging / dogfood databases.

I do agree that avoiding special cases is a good idea, and having
actual 'Person' objects for these things avoids special cases to
describe who took an action.

I think having different service accounts for these things is sensible
for a couple of reasons.

One is separation of concerns: its much easier to have a tightly
scoped role than to have one mega-powerful service account. If that
account were to be compromised, messy stuff would happen. Managing
more credentials is a tradeoff, of course.

Secondly, many (all) of the examples so far are great examples of
things we could run as external services. Its easier to identify
problematic clients if they have different ids.

In terms of where we might want to be:
* Code should be able to assert that a particular service account
exists and have it made just-in-time.
* We shouldn't conflate name-lookup for these Persons with regular
users: they should be exposed as Person (and so have a Person row) but
they should also exist in a dedicated 'internal service account'
namespace where their unique key cannot collide with the public name.
This would let us rename them safely in the public eye: our code would
lookup by the service name (which is what the existence assertion
would take).
* We should show them in a visually distinct way to educate folk about them.

We're not far off there. Minimally:
 * adding a service_name field to Person, with a UNIQUE constraint.
 * Adding a trivial API collection to show all persons with service names.
 * And a login code check that prevents such accounts logging into
OAuth or OpenID.

 would be enough to make it safe to write an existence assertion and
thus avoid further headaches with deployment skew.

How does that sound?
-Rob