ubuntu-appstore-developers team mailing list archive

[David Owen <david.owen@xxxxxxxxxxxxx>]

On 06/19/2013 04:03 PM, Martin Albisetti wrote:
> On Tue, Jun 18, 2013 at 6:57 PM, Colin Watson <cjwatson@xxxxxxxxxxxxx> wrote:
>> Yes.  I forget: do SSO tokens (i.e. login.launchpad.net, not a full LP
>> account) have a sensible name associated with them, or are they just a
>> hash?
> 
> They have a concept of "nickname" which is constructed based on the
> user's name and/or email address (hand waving here, Ricardo knows the
> details).
> It's not a UUID, but it may not always be pretty.

In SSO itself, there is a nickname that it grabs from Launchpad.  It may
change, and should not be used as a stable identifier for an SSO account.

There's the OpenID URL, which is the only good stable identifier for an
SSO account.

There is also some internal name based on cramming SSO accounts into
Django's included and ill-suited User model.  These names are not
exposed anywhere, really, except in the admin interface.  They are
completely useless outside of the admin interface.

If you use the django-openid package in your client application, it too
will cram information it receives from SSO into Django's ill-suited User
model, and create an "account name" like Django normally expects.  It is
derived from the nickname currently reported by SSO (which is the name
from Launchpad), and collisions are resolved by appending integers.  It
may occasionally match the nickname exactly, but really should never be
exposed or relied upon.

There have been many problems in the past with client applications
(summit was a major one, iirc) relying on either SSO's nickname field or
e-mail fields to be stable identifiers.  It causes major data problems
in the client, including detached client accounts, or client accounts
"accessible" from multiple SSO accounts, etc.  Don't do it.

The only identifier you should ever use from SSO to identify an account
is the OpenID URL.

-David