I am one who uses Mailman to support a closed community. Social logins are NOT a good thing there. Besides encouraging spam signups (social media accounts are easy to get - just ask the spammers), they tie your site to the privacy and other policies of the providers. This includes that when they authenticate, they also track users and sites. Monetizing the data. Many people find this objectionable. And not auditable.
When I tried to use MM3, turning off social logins was one of the first things I tried to configure. It wasn't easy. First I commented out too much, then too little. The resulting errors were opaque.
I hope things have improved - at present I keep an eye on MM3, but it's not usable for me at this time. So I may be somewhat behind the times.
The admin interface could use an authentication control panel - per site, and per-list. Click to enable/disable the social (password, 2-factor, and other plugin) providers.
On the whole, MM3 is far to painful to set up - editing hierarchies of config files assumes a technical person runs the list. Frequently, people who want lists aren't. [X} login with Google [x] login with passwords [x] login with GitHub is comprehensible - the implications may not be, but better to explain policies than how to edit a config file written in a foreign language.
There's a big difference between "installing" (that can assume some technical knowledge) and "configuring" (that should not). The former has to do with where you put files, how updates and time-driven events are enabled. The latter is how one expresses one's site policies/preferences.
Package managers and MaxKing's containers are "good enough" for installing. "configuring" by config files and extensive wiki searches is not.
The persistent echos of issues I raised and appear on the list from others are in the same vein. Cut and paste is not scalable for bulk subscribing thousands of users. Neither is API performance. Or "resent confirmation codes". or...
I recognize that replacing a mature technology is hard. MM3 has a lot of potential. It's just not there, for me, yet.
On 12-Feb-19 11:11, Stephen J. Turnbull wrote:
Note: I've changed the order of sentences from Torge's post to fit my responses.
Torge Riedel writes:
I do agree, same here on my side. Lot's of my users are very "sensitive" to social media and don't want see them here.
This is the first I've heard of this. Obviously it's fairly widespread; *please* speak up if anyone have similar issues that we haven't addressed. AFAIK all of the currently active Mailman developers believe that social auth is a GoodThang[tm], so we're unlikely to DTRT as you see it without your help.
I need to migrate from mailman2 to mailman3 and was wondering why social accounts are enabled by default
By default Mailman 3 is social media: you have a profile, you can be searched in the indicies of the archives, and so on. The large auth providers provide more secure authentication, and a lot of convenience for users who have such accounts already. They also take some administrative burden off the list and site managers when people lose their passwords and forget what their subscription address is, and similar scenarios. Clearly, these are not universally-valued features, but I think that they justify the current defaults.
and are difficult to disable.
They're easy enough to disable (easy to recognize and just add a hash character in front), since you have to edit settings_local.py to install anyway. If you're using a packaged version and the package configuration utility doesn't handle it, there's nothing we can do about it. The distro will have to deal with that.
It should be better documented, I imagine (haven't checked yet).
I propose something like an additional setting listing the enabled social accounts.
Do you mean in the Postorius administration interface? If so, do you want it by-site, by-domain, or by-list? ("You" is everybody who wants to disable social auth, not just Torge!)
If you mean in settings_local.py, I suggested something similar earlier. It's not obvious it would be easy to do (sometimes these things are order-dependent, though that's bad practice).
And if the admin is setting this to an empty value in the settings_local.py everything is disabled
Because the settings are a Python module, this is the way settings_local.py works anyway. That's why Mark suggested editing INSTALLED_APPS.
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- This communication may not represent my employer's views, if any, on the matters discussed.