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 have to be much more verbose (e.g. the
'HSTS_INCLUDE_SUBDOMAINS' key in SECURITY_MIDDLEWARE_CONFIG rather than
simply 'SECURE_HSTS_INCLUDE_SUBDOMAINS').
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.
As far as splitting up the middleware, I had similar thoughts as well. I
don't see a need to split up SecurityMiddleware, although it does seem
slightly inconsistent to have other middleware like XFrameOptionsMiddleware
which could just as easily be combined in SecurityMiddleware (as it was in
django-secure). Splitting it up would require adding more checks (one for
each miiddleware) which I wouldn't be wild about.
On Thursday, August 28, 2014 6:37:03 PM UTC-4, Carl Meyer wrote:
>
> 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 --deploy
> > --settings=settings_prod` to check your production settings file.
> > Running these checks automatically if DEBUG is False would likely give
> > them better visibility, but I don't see an easy way of disabling them
> > when testing if we did that.
>
> This makes sense to me. I don't like the fact that we assume in some
> places that "DEBUG off means production", and I would not prefer to add
> another such assumption here.
>
> > Regarding settings, would it be preferable to move them into a single
> > dictionary setting called something like SECURITY_MIDDLEWARE_CONFIG?
>
> Sure.
>
> FWIW, catching up on the thread, I fully agree with Russ that this
> should be in core, not contrib, and I agree with Aymeric and Russ that
> global config is better done via settings than via subclassing middleware.
>
> Carl
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/b7a82555-36f9-44df-be1b-3651043d8a35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
