Re: Setting dictionaries (was Re: integrating django-secure)

On 05 Sep 2014, at 23:18, Carl Meyer wrote: > On 09/05/2014 03:11 PM, Marc Tamlyn wrote: >> Yup, that works. The issue is that most users never explicitly call >> django.setup(), so they need to know how to modify manage.py and wsgi.py >> to do >> >> conf = MyProjectConfig()

Re: Setting dictionaries (was Re: integrating django-secure)

On 09/05/2014 03:11 PM, Marc Tamlyn wrote: > Yup, that works. The issue is that most users never explicitly call > django.setup(), so they need to know how to modify manage.py and wsgi.py > to do > > conf = MyProjectConfig() > django.setup(conf) > > > In the case of wsgi.py this isn't too

Re: Setting dictionaries (was Re: integrating django-secure)

Yup, that works. The issue is that most users never explicitly call django.setup(), so they need to know how to modify manage.py and wsgi.py to do conf = MyProjectConfig() django.setup(conf) In the case of wsgi.py this isn't too obtuse, but django.setup() is here -

Re: Setting dictionaries (was Re: integrating django-secure)

On 09/05/2014 02:54 PM, Marc Tamlyn wrote: > I like the idea Russ - from a brief peruse of the code base it's > apparently to me how disparate the handling of various "setup" settings > is throughout the codebase. For example: > > INSTALLED_APPS is handled by django.setup() and Apps.populate()

Re: Setting dictionaries (was Re: integrating django-secure)

I like the idea Russ - from a brief peruse of the code base it's apparently to me how disparate the handling of various "setup" settings is throughout the codebase. For example: INSTALLED_APPS is handled by django.setup() and Apps.populate() (cached attribute) MIDDLEWARE_CLASSES is handled by

Re: Setting dictionaries (was Re: integrating django-secure)

Hi Ryan, On 09/05/2014 12:02 PM, Ryan Hiebert wrote: > ​I'd like to see the email settings get moved into a dictionary so that > I can use a single environment variable to configure it very easily, ala > dj-database-url. There's dj-email-url right now, but it requires 7 lines > to configure

Re: Setting dictionaries (was Re: integrating django-secure)

Hi Russ, On 09/05/2014 10:38 AM, Russell Keith-Magee wrote: > The other way to resolve this would be to rethink the way Django starts up. > > Settings like MIDDLEWARE_CLASSES have always struck me as being a little > odd - they're not really settings, they're a way to configure the way > code

Re: Setting dictionaries (was Re: integrating django-secure)

On Thu, Sep 4, 2014 at 7:36 PM, Collin Anderson wrote: > I'm trying to think outside the box on settings. > > If we want to logically group settings together, what if we supported > syntax like this? > > MIDDLEWARE_CLASSES = ( >

Re: Setting dictionaries (was Re: integrating django-secure)

yeah... I thought of circular imports... you would need to lazy-load most imports. not fun. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: integrating django-secure

Over the past couple days, I've made some more updates and polish to the PR. A couple people have looked at it, but some more eyes would be appreciated as it's hopefully now in a mergeable state. Thanks! https://github.com/django/django/pull/3128 p.s. It uses flat, non-dict settings. We can

Re: integrating django-secure

On 09/01/2014 02:34 PM, Michael Manfre wrote: > On Mon, Sep 1, 2014 at 2:12 PM, Aymeric Augustin > > wrote: > > If we recommend HSTS, we need visible warnings and a small duration > in examples, for people

Re: integrating django-secure

On 09/01/2014 11:31 AM, Erik Romijn wrote: [snip] > So, although I encourage anyone to enable HSTS, we should not recommend > people to just "switch it on". They should be well aware of the > consequences as it can affect an unknown set of users beyond their > Django site, long after the change

Re: integrating django-secure

>> Hi all, >> >> I think finally integrating django-secure is a great step. Making a separate >> deploy check also makes sense to me. However, I think we should be very >> cautious with pushing people to enable HSTS. >> >> Some of our security headers can cause th

Re: integrating django-secure

Hi all, I think finally integrating django-secure is a great step. Making a separate deploy check also makes sense to me. However, I think we should be very cautious with pushing people to enable HSTS. Some of our security headers can cause things to break. For example redirecting to SSL when

Re: Setting dictionaries (was Re: integrating django-secure)

Le lundi 1 septembre 2014 09:15:21 UTC+2, Shai Berger a écrit : > > A case in point is a change that was introduced in 1.7 -- putting the TEST > settings of databases into an inner dict. When it was brought up, all > responses were positive. (...) (...) > As I said, everybody who commented on

Re: integrating django-secure

Le lundi 1 septembre 2014 02:07:40 UTC+2, Carl Meyer a écrit : > > Hi Claude, > > On 08/31/2014 12:08 PM, Claude Paroz wrote: > (...) > > > Once again, I'm not advocating for dictionary settings, only for fare > > debate :-) > > I hope you found this email fair ;-) > Thanks Carl for

Setting dictionaries (was Re: integrating django-secure)

This thread has had very little to do with django-secure for some time... On Sunday 31 August 2014 18:07:04 Carl Meyer wrote: > > In the case of the email settings, I think introducing a deprecation > that requires people to update their settings files, for zero gain in > capability, is a much

Re: integrating django-secure

Hi Claude, On 08/31/2014 12:08 PM, Claude Paroz wrote: > The situation about multiple user settings file is absolutely not > changed by that patch. If you import from a parent settings file, it's > still your choice to either overwrite the dictionary or update it, no > magics happen at all at

Re: integrating django-secure

Hi, I'm not against reverting #23384 (I'm the commit author) because I admit it can be debatable, but still I don't like that wrong arguments are given against it. The situation about multiple user settings file is absolutely not changed by that patch. If you import from a parent settings

Re: integrating django-secure

On 08/30/2014 07:28 PM, Tim Graham wrote: > If we drop magical merging of dictionary settings (which seems like it > will cause more confusion), a user's options for customizing a single > key in settings are: > 1. Redefine the entire dictionary in a project's settings > 2. Use the following

Re: integrating django-secure

The way the discussion has gone, I think I favor individual settings over settings grouped in a dictionary in this case. If we drop magical merging of dictionary settings (which seems like it will cause more confusion), a user's options for customizing a single key in settings are: 1. Redefine

Re: integrating django-secure

On Sat, Aug 30, 2014 at 8:33 PM, Josh Smeaton wrote: > > I think the problem becomes more pronounced when you want to override a > single sub-setting between your different environments: > > # base.py > > SECURITY_MIDDLEWARE = { > 'HSTS_SECONDS': 10, >

Re: integrating django-secure

-1 on using dictionaries to group somewhat related settings. Dicts make it much harder to override specific keys - and implementing a dict merge to get around a problem that we're creating ourselves for reasons of perceived attractiveness seems a little backwards. Mergingi If I want to

Re: integrating django-secure

I was initially indifferent about putting the django-secure settings in a dictionary, but the more I've thought about the more I feel Collin is correct; there is no real benefit (just an arguable sense of "tidiness") and there are several negatives (more verbosity in documentation, check warnings,

Re: integrating django-secure

On 30 août 2014, at 17:35, Collin Anderson wrote: > - It satisfies our craving for DRY > A _tiny_ more DRY, but it's _more_ code in your settings.py. Who wants to > type out all those quotes? > > - It artificially lowers len(dir(django.conf.global_settings)). > How is

Re: integrating django-secure

I still don't see the benefit to a dictionary. It's helpful for DATABASES and CACHES because there can be multiple of them. > It ensures that related settings remain grouped together. It seems to me a common SECURITY_ prefix should be good enough - It satisfies our craving for DRY A _tiny_ more

Re: integrating django-secure

On Saturday, August 30, 2014 2:48:10 PM UTC+2, Tim Graham wrote: > > If base.py adds CONTENT_TYPE_NOSNIFF and prod.py wants to add > HSTS_SECONDS, it would look like this: > Oh, that makes sense, I was so focused on "extending" that I didn't see that base.py could define a minimal dict

Re: integrating django-secure

The merging is between the final user settings and global_settings. The advantage is not having to redeclare all the keys in a setting like: SECURITY_MIDDLEWARE = { 'HSTS_SECONDS': 0, 'HSTS_INCLUDE_SUBDOMAINS': False, 'CONTENT_TYPE_NOSNIFF': False, 'BROWSER_XSS_FILTER': False,

Re: integrating django-secure

On Saturday, August 30, 2014 1:58:07 PM UTC+2, Aymeric Augustin wrote: > > On 30 août 2014, at 13:39, Florian Apolloner > wrote: > > > And what would that give us? if I want override FOO['BAR'] where from > would I override FOO with that merging behavior in place? > >

Re: integrating django-secure

On 30 août 2014, at 13:39, Florian Apolloner wrote: > And what would that give us? if I want override FOO['BAR'] where from would I > override FOO with that merging behavior in place? >From your settings file. -- Aymeric. -- You received this message because you

Re: integrating django-secure

On Saturday, August 30, 2014 12:58:18 PM UTC+2, Aymeric Augustin wrote: > > If it weren’t for backwards compatibility, we could recursively merge > dicts from user settings into defaults settings. For example > https://github.com/django/django/pull/3138 achieves that in > override_settings.

Re: integrating django-secure

On 29 août 2014, at 01:33, Tim Graham wrote: > There have been some other movements to consolidate settings into a dict > (e.g. #22734 for email settings) so it seems like we prefer this approach > despite the drawbacks. Indeed, I've noticed that grouping settings that

Re: integrating django-secure

Thank-you all for the feedback. The PR now uses a dictionary for the settings. A couple drawbacks to this approach: * It requires some logic in django/conf/__init__.py to allow users to override select keys in the setting while preserving the other defaults. * The docs and error messages will

Re: integrating django-secure

On 08/28/2014 06:44 AM, Tim Graham wrote: > I've implemented the ability to register "deployment checks" by adding > deploy=True to register: @register("tag_name", deploy=True). These > checks are only run if you pass the --deploy flag to check. So in > development you can run `manage.py check

Re: integrating django-secure

On Thu, Aug 28, 2014 at 8:44 AM, Tim Graham wrote: > I've implemented the ability to register "deployment checks" by adding > deploy=True to register: @register("tag_name", deploy=True). These checks > are only run if you pass the --deploy flag to check. So in development

Re: integrating django-secure

On Thursday, August 28, 2014 2:44:08 PM UTC+2, Tim Graham wrote: > > Regarding settings, would it be preferable to move them into a single > dictionary setting called something like SECURITY_MIDDLEWARE_CONFIG? > Definitely. -- You received this message because you are subscribed to the

Re: integrating django-secure

I've implemented the ability to register "deployment checks" by adding deploy=True to register: @register("tag_name", deploy=True). These checks are only run if you pass the --deploy flag to check. So in development you can run `manage.py check --deploy --settings=settings_prod` to check your

Re: integrating django-secure

The settings for the SecurityMiddleware as they appear in django-secure are: SECURE_HSTS_SECONDS=0 SECURE_HSTS_INCLUDE_SUBDOMAINS=False SECURE_CONTENT_TYPE_NOSNIFF=False SECURE_BROWSER_XSS_FILTER=False SECURE_SSL_REDIRECT=False SECURE_SSL_HOST=None SECURE_REDIRECT_EXEMPT=[] Yo-Yo, would be

Re: integrating django-secure

+1 on basically adding the functionality of checksecure to the default validation. -1 to adding the middleware. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an

Re: integrating django-secure

On Thu, Aug 28, 2014 at 1:53 PM, Aymeric Augustin < aymeric.augustin.2...@polytechnique.org> wrote: > Le 28 août 2014 à 03:25, Tim Graham a écrit : > > I am fine with putting it in core instead of contrib. That just means we > need to figure out what to do about settings

Re: integrating django-secure

> Le 28 août 2014 à 03:25, Tim Graham a écrit : > > I am fine with putting it in core instead of contrib. That just means we need > to figure out what to do about settings since we cannot put them on an > AppConfig. Assuming we don't want to add them as normal settings,

Re: integrating django-secure

t;timog...@gmail.com >> > wrote: >> >>> I've started tackling one of the ideas that's been on our GSoC ideas >>> page for a couple years now: integrating django-secure. I chatted with >>> Carl about the idea and he's onboard. There are a couple of desi

Re: integrating django-secure

ith-magee.com> wrote: > Hi Tim, > > On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham <timogra...@gmail.com> wrote: > >> I've started tackling one of the ideas that's been on our GSoC ideas >> page for a couple years now: integrating django-secure. I chatte

Re: integrating django-secure

Hi Tim, On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham <timogra...@gmail.com> wrote: > I've started tackling one of the ideas that's been on our GSoC ideas > page for a couple years now: integrating django-secure. I chatted with > Carl about the idea and he's onboard. There are a c

integrating django-secure

I've started tackling one of the ideas that's been on our GSoC ideas page for a couple years now: integrating django-secure. I chatted with Carl about the idea and he's onboard. There are a couple of design decisions we'll need to make. 1. How to integrate django-secure with the checks framework