On Fri, Jan 29, 2016 at 12:56:32PM +0100, Simon Hanna wrote:

Mozilla is dropping Persona and shutting it down later this year [1].

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.

I think this makes sense. Reinventing the wheel is often quite wasteful, especially when there are decent existing solutions available already.

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.

I can think of several use-cases where managing multiple email addresses in the same place could be exceptionally useful and a good win for UX.

-- "Youth cannot know how age thinks and feels. But old men are guilty if they forget what it was to be young" -- Ch37, Order of the Phoenix, JK Rowling

Barry Warsaw writes:

Further, I have a strong personal preference for "no user names", or alternatively, using email addresses as their "user name". I think user names are essentially contrived extra information for which there's no need, when clearly your identity is your email address.

Clearly that's *an* identity, yes, and for social and volunteer sites it's one of the few things that is operationally verifiable for most users (except for those wonderfully expressive and mnemonic, not to mention easy-to-type, PGP keys!), so some email address should be the "main" user identifier. OTOH I don't see why a person having an (optional, additional) nickname is bad.

We've long debated, but never attempted, a "centralized user database" component, partly because we can't decide whether that should be a separate piece that the core, Postorius, and HK (and at some point, mailmania) talk to, or whether it should just live in the core.

Another problem is Mailman in the enterprise, which probably has its own database already.

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

On 2016-01-29 18:50, Stephen J. Turnbull wrote:

Simon Hanna writes:

...

I propose using the django authentication system by default and making it easy for people to add other authentication methods.

I think we should provide social auth (OAuth2 or whatever Google and Yahoo! do) by default. At least as I recall the discussion at the sprints a couple years ago, we picked Persona because a Mozilla person gave us a lot of help with the implementation, but we really wanted social auth because users demand it and because it allows us to get out of the business of storing and securing passwords.

I can only speak for me, but I liked Persona because it allowed people/email providers to implement their own backends, giving them a real possibility to handle the authentication themselves with Persona merely being a technology or a broker. Also the fact that Mozilla is a Non-Profit which doesn't aim at making money from user data. Which is why I would rather make the local option the default, but give site admins everything they need to integrate OAuth(2) using Gmail, Yahoo, Twitter or else.

Florian

On 01/29/2016 08:59 PM, f@florianfuchs.com wrote:

On 2016-01-29 16:00, Barry Warsaw wrote:

...

From a UX perspective, I do want to allow people to log into their accounts using any of their registered and validated email addresses. People very often forget just which address is subscribed to which mailing list, so it really shouldn't matter which one they use to get into their account.

We should check out which external app allows for multiple emails to be set. Or which ones allows for easy customization to do so at least.

...

Further, I have a strong personal preference for "no user names", or alternatively, using email addresses as their "user name". I think user names are essentially contrived extra information for which there's no need, when clearly your identity is your email address. I liked this about Persona.

I agree, especially since even though we now have HyperKitty, there will probably always be many folks whose interface of choice for Mailman is email, and who will not use the interface very often. Remembering usernames for sites you last visited 20 months ago is awful.

I just found another solution: django-allauth http://www.intenct.nl/projects/django-allauth/ http://django-allauth.readthedocs.org/en/latest/overview.html https://github.com/pennersr/django-allauth

It's a relatively large project. It has 2000+ stars and about 800 forks on github. The other two I introduced can't get these values when adding them together.

About their functionalit quoting from their docs:

• Signup of both local and social accounts
• Connecting more than one social account to a local account
• Disconnecting a social account – requires setting a password if only the local account remains
• Optional instant-signup for social accounts – no questions asked
• E-mail address management (multiple e-mail addresses, setting a primary)
• Password forgotten flow
• E-mail address verification flow

They are basically supporting every OAuth provider out there

They have more signals than the other two projects I introduced. Some of them are:

• when a user signs up
• when a user adds an email
• when the user removes an email

I didn't look at the code yet but I think they are only using emails and not usernames.

I will try to integrate it in the next couple of weeks and see if we should create a sepparate app for that or do the work in both projects

I just found another solution: django-allauth http://www.intenct.nl/projects/django-allauth/ http://django-allauth.readthedocs.org/en/latest/overview.html https://github.com/pennersr/django-allauth

It's a relatively large project. It has 2000+ stars and about 800 forks on github. The other two I introduced can't get these values when adding them together.

About their functionalit quoting from their docs:

• Signup of both local and social accounts
• Connecting more than one social account to a local account
• Disconnecting a social account – requires setting a password if only the local account remains
• Optional instant-signup for social accounts – no questions asked
• E-mail address management (multiple e-mail addresses, setting a primary)
• Password forgotten flow
• E-mail address verification flow

They are basically supporting every OAuth provider out there

They have more signals than the other two projects I introduced. Some of them are:

• when a user signs up
• when a user adds an email
• when the user removes an email

I didn't look at the code yet but I think they are only using emails and not usernames.

I just opened a merge request over at postorius https://gitlab.com/mailman/postorius/merge_requests/91

It includes basic functionality for django-allauth. All the included code should work, the merge request contains info about what still needs to be done. What do you think?