I brought this question up on Github and received the solution from maxking:

https://github.com/maxking/docker-mailman/issues/283

In particular:

"In your settings_local.py copy the whole INSTALLED_APPS section from default settings and add/remove the auth providers you want/don't want. Notice the allauth.socialaccount.providers.<provider> in the list below."

Hope that helps. Brian

On 02/10/19 at 08:57, brian@emwd.com brian@emwd.com wrote:

"In your settings_local.py copy the whole INSTALLED_APPS section from default settings and add/remove the auth providers you want/don't want. Notice the allauth.socialaccount.providers.<provider> in the list below."

Another option, which seems more future-proof, is to strictly remove the account providers you don't want from INSTALLED_APPS rather than defining INSTALLED_APPS locally.

First, you have to access INSTALLED_APPS by importing settings into settings_local.py:

from settings import *

Then, you can set INSTALLED_APPS to everything it already is minus the social providers:

INSTALLED_APPS = [a for a in INSTALLED_APPS if not a.startswith('allauth.socialaccount.providers') and not a.startswith('django_mailman3.lib.auth.fedora')]

This way if Postorius ever adds any apps you won't need to update your local settings. Anyone see any downsides to doing it this way?

-- Nick Wynja https://nickwynja.com

Nick Wynja writes:

INSTALLED_APPS = [a for a in INSTALLED_APPS if not a.startswith('allauth.socialaccount.providers') and not a.startswith('django_mailman3.lib.auth.fedora')]

This way if Postorius ever adds any apps you won't need to update your local settings. Anyone see any downsides to doing it this way?

Aside from the circular import issue mentioned by Abhilash

1. AIUI, the OP didn't want to present options to users that they don't need and might confuse/annoy them. This does the wrong thing for the OP if so.

2. Implicitly adding apps in this way increases the attack surface on the system by allowing additional opportunities to access resources.[1] This approach doesn't even necessarily get rid of all social authentication providers: others may be special-cased in the same way as Fedora in the future.

   Of course, the default configuration in the containers will be good for a very common use case, and sufficiently secure for most instances. But the general rule for Internet-facing applications is "shut off all access by default, and explicitly open up only the channels you need." I'm not saying your "subtract the social authentication applications" has a downside in all cases. Just that some of us prefer to expend the effort to (a) follow that general rule, and (b) advise others of its existence :-).

Footnotes: [1] You're right, the admin has to intervene if Mailman adds new "must-install" apps, or Postorius won't run. It's possible we should do something about this, such as dividing the set of apps into those we are sure Mailman needs and and having the user configure only those that provide more or less optional features that users should make their own decisions about.

Abhilash wrote:

Having the list customized is actually good for you, since there is some extra configuration required for adding a new provider, so you don't want something to just show up without you knowing.

Stephen wrote:

But the general rule for Internet-facing applications is "shut off all access by default, and explicitly open up only the channels you need." I'm not saying your "subtract the social authentication applications" has a downside in all cases. Just that some of us prefer to expend the effort to (a) follow that general rule, and (b) advise others of its existence :-).

Thanks, this is helpful. I'll stick with the configuration as Abhilash suggested.

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.

Am 12.02.19 um 17:11 schrieb Stephen J. Turnbull:

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.

Well most of my users are 60+ so social media is some kind of a thing from hell for them ;-) I don't want to blame it, but to ensure acceptance in my scenario it is required to hide them somehow.

...

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.

Yes, this was a bit unprecise. For my feeling it is better to enable one after another, but it is ok for me to do it the other way.

...

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).

Having the configuration in the UI would be the best solution. So not everything needs to be done by me. A first approach is the mentioned setting, which can be set to an empty value to overwrite the default. Without the risk to break something else. Just to repeat.

...

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.

Thanks so far for going into the discussion.

Hi Stephen,

thanks for your follow-up and the discussion about ID providers.

Stephen J. Turnbull:

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.

As the Mailman3 Debian Maintainers, we decided to disable social auth in the mailman3-web Debian package alltogether.

That's because in general, we try to avoid "calling home" features in software when it's possible. Usually, these "call home" features are abused to track users behaviour. With Mailman3, it's not directly calling home. But still, adding so-called "social" authenticators to the mailman3 django application will expose users to the risk of clicking on those ID provider buttons.

...

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.

Personally, I consider it a major privacy issue if one central instance (e.g. Facebook) is able to track on which platforms and services you authenticate.

And to be honstes, I'm a bit irritated that those tracking features from big corporates like Facebook and Google, whose main business model is to aggregate as as much private data points as possible about as much users as possible are enabled by default in Mailman3 upstream.

Besides the privacy concerns raised above, on problem with central authentication services is that they also create new single points of entry/failure. If your Facebook account gets hacked, you now loose control over all other services/platforms, that you used the Facebook authenticator service for.

...

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!)

I agree with Torge that those social auth providers should be disabled per default. IMHO, A sane default would be to list them in the settings.py but have them commented out.

Cheers jonas

Jonas Meurer writes:

But still, adding so-called "social" authenticators to the mailman3 django application will expose users to the risk of clicking on those ID provider buttons.

I can see this point for Debian users. I suspect Ubuntu users are somewhat less paranoid. :-)

Since that risk holds even for sites that enable explicitly (assuming we adopt the same policy) I will take a look at making that risk hard to realize (more distance from anything else clickable, smaller buttons with visible and accurate boundaries.

Personally, I consider it a major privacy issue if one central instance (e.g. Facebook) is able to track on which platforms and services you authenticate.

Sure, but that ship has pretty well sailed AFAICT. Most users use unconfigured versions of IE (or Edge) and Safari, which means they're subject to all manner of webbugs. My employer just asked me to stop using Firefox because it's too pedantic for their website development vendors. :-( GDPR enforcement seems to primarily be an arm of the EU trade offensive against large American services (that's the Economist's recent opinion, not mine), while Europe-based globals are undoubtedly doing the same crap.

And to be honstes, I'm a bit irritated that those tracking features from big corporates like Facebook and Google, whose main business model is to aggregate as as much private data points as possible about as much users as possible are enabled by default in Mailman3 upstream.

Your irritation is not our problem, though, since you can use Debian's version, and as I mentioned earlier, as far as I know most of our sites are happy to have social auth. I will be paying attention to the list to see what others think.

Besides the privacy concerns raised above, on problem with central authentication services is that they also create new single points of entry/failure. If your Facebook account gets hacked, you now loose control over all other services/platforms, that you used the Facebook authenticator service for.

Same thing if you use a weak password. Effective and secure authentication is not something we're good at, and we can't really afford the effort to be good at it. These things are tradeoffs, and the default should be something that most of our users (ie, site and list admins, NOT subscribers) want. Hopefully their preferences in this respect reflect those of *their* users (== subscribers).

I agree with Torge that those social auth providers should be disabled per default. IMHO, A sane default would be to list them in the settings.py but have them commented out.

"Those" social auth providers? Are there social auth providers who provide what you consider acceptable privacy guarantees (a la Duck-Duck-Go in search engines)? If so, we could make those higher in the list/easier to use.

This has been a very interesting discussion.  We should be mindful that it is occurring all over society.  It is arguable, and I hope true, that the worm has turned regarding privacy.  People are starting to realise that you always  (in the general case) are paying for a service.  If not with money then with something else.  In some cases both (hello square space!)

tl;dr  The choice for or against using the big bad corporation services needs to be clear and usable.  Privacy is a minority interest today but IMO the writing is on the wall and for web services it will become the wolf in the kitchen.

On 14/02/19 3:42 PM, Stephen J. Turnbull wrote:

Jonas Meurer writes:

...

But still, adding so-called "social" authenticators to the mailman3 django application will expose users to the risk of clicking on those ID provider buttons.

I can see this point for Debian users. I suspect Ubuntu users are somewhat less paranoid. :-)

Since that risk holds even for sites that enable explicitly (assuming we adopt the same policy) I will take a look at making that risk hard to realize (more distance from anything else clickable, smaller buttons with visible and accurate boundaries.

Better that it is off, or it is on for a selected group of providers. The issue is not the prominence of social login options but the presence. I disagree that accidental clicking on social login widgets is a major issue, but I have no data, so it is a opinion.

...

Personally, I consider it a major privacy issue if one central instance (e.g. Facebook) is able to track on which platforms and services you authenticate.

Sure, but that ship has pretty well sailed AFAICT. Most users use unconfigured versions of IE (or Edge) and Safari, which means they're subject to all manner of webbugs. My employer just asked me to stop using Firefox because it's too pedantic for their website development vendors. :-( GDPR enforcement seems to primarily be an arm of the EU trade offensive against large American services (that's the Economist's recent opinion, not mine), while Europe-based globals are undoubtedly doing the same crap.

The ship has not sailed.  We can get back what we have lost.  The new generation of web developers are, in my experience, too enamoured with the cool stuff they can do, and ignore old grey beards (like myself) talk of "attack surfaces" and "chains of trust" and blithely install google fonts, load javascript from CDNs, etcetera that gives their user's data away without a thought or regret. Ten milliseconds and 20kb is considered too high a price to pay for enabling some body else's privacy.  But they are starting to face push back from consumer groups who understand the value of what is being handed over.

...

And to be honstes, I'm a bit irritated that those tracking features from big corporates like Facebook and Google, whose main business model is to aggregate as as much private data points as possible about as much users as possible are enabled by default in Mailman3 upstream.

Your irritation is not our problem, though, since you can use Debian's version, and as I mentioned earlier, as far as I know most of our sites are happy to have social auth. I will be paying attention to the list to see what others think. That irritation is exactly the problem.  It is a problem we need much more of.

...

Besides the privacy concerns raised above, on problem with central authentication services is that they also create new single points of entry/failure. If your Facebook account gets hacked, you now loose control over all other services/platforms, that you used the Facebook authenticator service for.

Same thing if you use a weak password. Effective and secure authentication is not something we're good at, and we can't really afford the effort to be good at it. These things are tradeoffs, and the default should be something that most of our users (ie, site and list admins, NOT subscribers) want. Hopefully their preferences in this respect reflect those of *their* users (== subscribers).

Attack surfaces.  "Whataboutism" is not a valid argument against the argument that you should decrease your attack surface.

But  social authentication is enabled are the trackers are not loaded too. As far as I can see. If so that is a good thing.  The big bad corporates only get data when some one actually uses their services.

...

I agree with Torge that those social auth providers should be disabled per default. IMHO, A sane default would be to list them in the settings.py but have them commented out.

"Those" social auth providers? Are there social auth providers who provide what you consider acceptable privacy guarantees (a la Duck-Duck-Go in search engines)? If so, we could make those higher in the list/easier to use.

I disagree that they should be disabled by default.  I agree they should be disabled, but it should be by choice.  What is required is a configuration option in the interface not in the text configuration files.  The former is for list administrators the latter is for site administrators.  Currently list administrators do not have that choice.  (I am new here, do I have that correct?)

Worik

-- If not me then who? If not now then when? If not here then where? So, here I stand, I can do no other root@worik.org 021-1680650, (03) 4821804 Aotearoa (New Zealand)

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.

Maybe there is a possibility for a simple approach via config file:

EXTRA_LOGINS = no

Insufficiently flexible, I think. ENABLED_EXTRA_LOGINS (more likely to be named ENABLED_AUTH_MODULES or similar) is more flexible.

ENABLED_EXTRA_LOGINS = []

Under consideration, it's been suggested in several forms already.

Thank you for your suggestions.

Steve

-- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN

Jonas Meurer writes:

But in my eyes, software developers, package maintainers and system administrators all should do their best to protect their users from privacy and/or security threats.

Me too. Passwords are a well-known vulnerability, providing a large attack surface. I'd rather not burden Mailman providers with protecting their users' credentials, other things being equal. They're not, so we have to decide (individually and as a project) which vulnerabilities are more frightening, and how much configurability to provide, and how.

Probably we have a different opinion on whether providing usage of authentication providers which earn their money by collecting users' data exposes users to privacy threats.

We do not. We differ on the importance of those vulnerabilities to the users.

I have a different opinion on this. You're correct that most users know next to nothing about protecting themselves against all kinds of threats on the internet. But to me this shows even more, that we as those who build the tools have a responsibility to protect our users against shooting themselves in their foot.

See my reply to Worik on this.

But that doesn't mean that we as independent and free software developers have to agree on the dangerous interfaces and standards those corporates develop (for their business!).

Sure. This is a valuable service which for most users reveals very little information: the domain and IP that the user wants to authenticate to. If I were the type to visit porn or RWNJ sites, I wouldn't use GMail as my auth provider, and I'd probably use Tor as my ISP. I have no problem with using Gmail as my auth provider to Google Summer of Code (!) and Github.

Why do you think it's a problem to allow users to make the choice? As I mentioned to Worik, I wouldn't mind allowing customization of the interface, with a warning displayed about social auth. I do not see any argument for preventing them from making the choice.

My irritation was mainly about what I wrote above: that the privacy concerns against authentication providers from big corporates seem to be of low priority when deciding about defaults in Mailman3 upstream.

Then you misunderstand. We explicitly made the decision to emphasize social auth *in part* because *as authentication* is far more secure than (1) passwords and (2) most mom and pop sites. I'll grant that the "coolness" and user demand factors matter, too. And the privacy implications generally seem minor with a few exceptions (see the mentions of "DV" in my message to Worik).

To be honest, I've never evaluated the privacy implications of OpenID. From a first glance, it looks *way* better.

AFAICS (first glance in several years), OpenID is no better: the on- the-wire information is provided in basically the same way, and it looks like the content is arbitrary. The FAPI (financial information) and HEART (health information) protocols look especially tasty to big data users/privacy invaders The question is what do the providers provide (account identifier, real name, address, gender orientation, where you buy your illegal drugs ...) and what the client asks for (Mailman asks if user credentials are valid).

But for sure, Github, Google, Facebook, Stackexchange and Twitter all rely on collecting users data for their business model. So it's probably not a good idea to share with them the information which platforms and services you authenticate against, *if* you care about privacy.

I'm far more worried about the video cameras that are everywhere nowadays, hacks of government databases, people who record "private" conversations in person and otherwise, and which of my passwords are going to show up on haveibeenpwned.com next week.

Steve

Mark Sapiro writes:

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 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.

That's a different issue from the one I believe Torge is worried about, which is an update overwriting settings_local.py. But it's not good.

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.

I don't understand the ramifications of making this change (presumably Barry or somebody had a reason for the change from Mailman 2's method), but at first glance it looks like a big step in the right direction.

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.

Given the concerns of privacy advocates, I would say that it would be better to have a separate

AUTH_PROVIDERS = ['allauth.socialaccount.providers.google', ...]

in settings_local.py, and merge that in to INSTALLED_APPS. Of course removing specific providers would be OK too, but I think that this is a place where "deny all / accept what you want" is appropriate.

Steve

-- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN

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)