[Mailman-Developers] Dropping Persona

[f at florianfuchs.com]

On 2016-01-29 12:56, Simon Hanna wrote:
> Hi,
> 
> Mozilla is dropping Persona and shutting it down later this year [1].

Yeah, that's such a shame.

> Postorius and Hyperkitty will have to drop it, and use something else
> as a default login mechanism.
> 
> I propose using the django authentication system by default and making
> it easy for people to add
> other authentication methods.

In fact, technically, the django auth system is what we were using all 
along, since our browserid integration was a layer on top of that.

I agree we should still have something in place for site admins to allow 
using others methods like OAuth. But we can keep python-socialauth for 
that I think. It's a bit more hassle for admins to configure than 
Persona though.

> If we go with django authentication we can either build everything
> ourselves (I did it for a couple
> of projects myself) or use some provided project. This is because
> django doesn't offer registration
> views and email confirmation. Also password changing and password
> resetting will have to be added.
> 
> I know of two projects that do that already:

Thanks for investigating!

> django-user-accounts [2]
> It's part of the pinax platform, but can be used independently of the
> other components. It comes
> with everything we need and not much more. Note that the profiles of
> django-user-accounts can
> contain additional emails, which we probably don't want. It's
> officially supporting django 1.8 and
> 1.9. I'm not sure about our django dependency policy but since
> upstream has marked all pre 1.8 as
> being out of date, I think that we can move on as well...

Oh, I think we *do* want additional emails. On a Mailman core level 
there can be multiple email addresses associated with one account. Being 
able to keep these tied to one Django record would be very good.

> django-userena [3]
> Pretty much the same as django-user-accounts but it has additional
> "features" like messaging which
> we definitely don't need. It's not yet django 1.9 compatible but there
> is a merge request that adds
> support for it.

Some kind of messaging would be good, so we can hook into new 
registrations and, for instance, create new accounts on the core level. 
Although we already do that using Django signals. So I agree, another 
messaging system is probably not needed.

> Since we have two projects to maintain, I'd rather go with an external
> app. I guess it would be
> easiest to have exactly the same configurations for Postorius and
> Hyperkitty. In order to not
> duplicate any templates and other code, I'd propose to create a third
> project that has all the
> account functionality and put everything we need in there.
> In case we go with doing everything ourselves, I guess it's still
> better to create a separate app
> for that.
> 
> My personal favorite is django-user-accounts for which I have some
> basic functionality in a merge
> request for Postorius so you can have a look at what needs to be 
> changed. [4]
> 
> 
> Regardless of what approach we choose, we should also think of 
> migrations.
> Existing internal django accounts can be easily migrated. We'll have
> to choose if we want to migrate
> the "social" accounts as well or just tell people to sign up again.

The existing social accounts do already exist locally, since for each 
new Persona login a new user record is created. Only there's no usable 
password (since they used persona to authenticate). But if a new app 
also sits on top of the default django auth system *and* can create new 
passwords for existing records, we might not even have to do a lot to 
give folks access to their accounts.


Florian