Hi,
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.
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:
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...
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.
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.
We still have time for the transition, but I'd prefer dropping persona before the 3.1 release if that happens to come before the shutdown.
What do you think?
Simon
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
On Jan 29, 2016, at 12:56 PM, Simon Hanna wrote:
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 don't have any sense about which technology to adopt, but I do agree it probably makes sense for Postorius and HK to be compatible here. So I'll leave technology choices and migration schedules up to Aurelien and Florian.
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.
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.
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. I've resisted putting it in the core because it would have little use for it, and I like to keep it as lean and narrowly focused as possible. But perhaps, if such a component makes sense for a better UX for the user facing bits, then we can open that discussion up again.
We still have time for the transition, but I'd prefer dropping persona before the 3.1 release if that happens to come before the shutdown.
The big feature for 3.1 from the core's perspective is reliable upgrades from MM2.1. I know that Aurelien has been working hard on that, and that there's still one MR to deal with (#32), but I am thinking out loud that if not before, the Pycon 2016 sprints would be a good time to release 3.1.
Cheers, -Barry
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 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.
We still have time for the transition, but I'd prefer dropping persona before the 3.1 release if that happens to come before the shutdown.
The big feature for 3.1 from the core's perspective is reliable upgrades from MM2.1. I know that Aurelien has been working hard on that, and that there's still one MR to deal with (#32), but I am thinking out loud that if not before, the Pycon 2016 sprints would be a good time to release 3.1.
If we can't make the transition into 3.1, we're going to make another release before November, since that's when Persona is getting shut down for good. So I'd say it's a good idea to at least try to get it into 3.1.
Cheers 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?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/01/16 10:00, Barry Warsaw wrote:
The big feature for 3.1 from the core's perspective is reliable upgrades from MM2.1. I know that Aurelien has been working hard on that, and that there's still one MR to deal with (#32), but I am thinking out loud that if not before, the Pycon 2016 sprints would be a good time to release 3.1.
Cheers, -Barry
I added that idea to https://us.pycon.org/2016/community/sprints/ .
Sumana Harihareswara http://brainwane.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJWwTjaAAoJECR5sh+1fa+cmUYQALI8fnL9fnVQYXpIwVxDROsK ot/PwAnYzu4pFEU9hUeipz4tfO6X2BtgIBHfnR09tWUrAAy4UqHN33zKPqsSS8eq coqTbL0uYLrU51C7Lht0Bp6ZJufioTCtjSW41x5t0U3sVjrqIr8ICLasgJfee5i0 xS9jKmG/sGs1rnAFz/uUMNqEP0siy5REh8WvLrgEUNSLf/5wtGwz2nCrAIMeTk3W J8Cy4eg9qNa/mBjuqgObtRIErUbqqaCc5Rdq5BSUXsAltR3G+UOsuEgP9tuobGwl 76tCqdFEniy7wA2TOrsqDmei6WiffmIFS9Z6JC2Zn7FUxGjIP9gmjZMoNPXa99tY tt2ACzM/5sdITQhzjhtc4eQLe0pYeCbXkc7Xxam8JOl+jzgzs39iNK156H9OpJI1 pwYGFRlaDJPdSYC+tZzfhtXkLYm42Vz5YZtihyTG4XXdbTXeXG7zx0lASMGybfe/ 1OnSCgaTYPvuOzpPLZqQd7OykfhrozFenY4dytbgj0VZ4CQHtXUMybR7AAC5APjB Yf5Hn0IxgNX7KcLNW4NF5vU1wyrlzVY4UhS5fhu0yk9aaEfSdkeUzwmX53z1HpCa RdqEoQJctOGMds6fLe3XT9DIcX+1xYOJ+QYFeFrayqxEIOROynA1z12ezTIRNeo3 8EBTLftoTlZbmrf1cokA =FIoI -----END PGP SIGNATURE-----
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.
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
I disagree, but this being a GNU project it's the party line to deprecate security and privacy in favor of freedom. I won't push the issue of defaults any further since we agree the OAuth option should be available.
f@florianfuchs.com writes:
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.
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
participants (6)
-
Adam McGreggor -
Barry Warsaw -
f＠florianfuchs.com -
Simon Hanna -
Stephen J. Turnbull -
Sumana Harihareswara