This is kind of a top-post, because I am not sure which message should my reply quote. Please excuse that part.
My thinking on this topic resonates with what Steve said, I don't think we should be forcing the Mailman Administrators to handle username passwords. Dare I say that most social auth providers have more incentive and money to keep their database secure than Mailman Administrators.
Having said that, it doesn't have to be either or between "social logins enabled by default" and "I don't want to see a Facebook button". I have actually thought about this before, but never have been able to get to it. I opened an issue too but can't find it right now.
Anyway, so the idea is that most social providers need some soft of configuration from the Admin. Today, we enable them by default, but they don't work by default. I think we could make both sides happy if we were to just not show the social providers that aren't configured. What do others think?
Only two providers that I know of in Mailman's default list, which don't need any configuration, are Fedora and OpenID. I am happy to remove OpenID from default since I have never been able to actually get that to work. I am okay with removing Fedora too, which is a special case in Mailman 3 because of fedoralists.org being the first customer for Mailman 3 and Hyperkitty.
I don't have cycles to do that myself right now, so I would encourage people to step up to tackle this. I would obviously help them out with any Python, Mailman or Django related questions they might have.
Now, about the ease of being able to disable social logins, I think it should be possible to disable social logins with just a boolean flag in settings. Why haven't we done it yet? We didn't need to. What we provided was a **sample configuration**, with a huge emphasis on sample. We weren't maintaining it as an official set of configurations, but just something that one could use as a starting point. But that obviously didn't happen since people just downloaded and used it, some of which is ofc my own fault since the official docs doesn't say that what precisely you should be worried about changing from the sample.
The beauty (and ugliness) of Django's settings.py is that it is Python. We can disable social login if your CPU heats up1, or if the stock price of the company goes below (or above? :P) a threshold, or heck, if the network firewall detects a packet heading out to their servers.
How Django's configuration works has been left kind-of open by the Django devs themselves, making every downstream project handle their own use case separately. We chose to just go with what was provided out of box, but that doesn't mean we can't do any better. We can do ini-style configs, it gets a tad bit complicated when there are unknown Python data structures that can't easily be represented in ini-style. We could do YAML, which supports more complicated data structures (nested maps and lists). OR, we could do JSON, but I find that less human readable.
Next topic, people worrying about customizing settings in settings_local.py and worrying about not getting newer updates. Isn't this how rest of the packaging and configuration world works? If you customize the /etc/postfix/main.cf you don't get the updates to default config (apt asks you, but you will choose not to update with your custom settings, right?) when you upgrade your postfix package from Debian and you need to pull in any new settings that package supports manually.
I have been (silently) working2 on making the mailman_suite project a Python package (mailman3-web), like the Debian Maintainers did. That would be the right place to put whatever configuration logic we want to expose to our users. We can move to a model where you'd import all the settings from mailman3_web.settings.base and then customize all the fields that you do care about. But there will be downsides to it, like us updating a setting that changes the behavior of an already working site, and we can sure document those changes in release notes in big bold letters, but I still worry there will be people running pip install -U without thinking what does that even mean.
I don't know what should we do? What do other people managing configurations do? Maybe Debian Maintainers can chime in here?
On Fri, Feb 15, 2019, at 8:43 AM, Mark Sapiro wrote:
On 2/14/19 11:10 PM, Stephen J. Turnbull wrote:
Torge Riedel writes:
- there is a way to do this now via settings_local.py, but feels a little bit risky if default configuration changes on update of mailman
This should not be true. If it is, we need to fix that. Will check.
It is more or less true. The issue is that unlike mm_cfg.py and Defaults.py in Mailman 2.1, the recommended way to set up Django in Mailman 3 is to point Django at settings.py for the default config, and the last thing in settings.py is
try: from settings_local import * except ImportError: pass
Thus,the only way settings_local.py can change something like INSTALLED_APPS is to redefine INSTALLED_APPS in it's entirety which leads to the possibility of INSTALLED_APPS changing in settings.py and those changes not being picked up in settings_local.py.
The way around this is to remove the import of settings_local from settings.py and then put
from settings import *
at the beginning of settings_local.py and then point Django at settings_local rather than settings.
Then you can do things like
try: INSTALLED_APPS.remove('allauth.socialaccount.providers.google') except ValueError: pass
in settings_local.py except there are still issues because, e.g., INSTALLED_APPS is defined as a tuple (immutable) and not a list in settings.py.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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/
-- thanks, Abhilash Raj (maxking)