Hi Tim, On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham <[email protected]> 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 design > decisions we'll need to make. > +1 to the idea. It was part of Chris' original proposal; we just didn't get around to it with the available time. > 1. How to integrate django-secure with the checks framework > django-secure essentially implements its own checks framework (which > predates the one in Django). The tricky part is that django-secure's > checks are not ones that generally should pass on a > development instance; they're checks that only make sense to run on a > production server (or at least against a production settings file). > I'm thinking to have some way to skip these new checks by default and > run them only when requested (e.g. manage.py check secure > --settings=prod_settings). Other options include an entirely separate > command like django-secure implements (curently called checksecure), > but perhaps could be called checkdeploy and eventually extended with > other checks that are relevant only in production. Idea/insight from > those more familiar with the checks framework (Chris, Russ), would be > welcome. > Generally, I'd be opposed to the idea of Yet Another Command to run checks - if you make it optional, it won't get run, and this is something we want to be forced in front of everyone. We use DEBUG as a proxy for "In Production" in other locations in the codebase - e.g., whether ALLOWED_HOSTS checks are run. If we were to supplement that with a --production=true/false flag to the checks command (to override the rare legitimate occasions where DEBUG=True in production, or DEBUG=False in development), wouldn't that meet all the needs here? 2. How to add settings for django-secure > As discussed in the thread below, I'm going to explore developing an > API for storing settings on an AppConfig to avoid adding more global > settings. > https://groups.google.com/d/topic/django-developers/qnnCLppwA3o/discussion > > I have imported django-secure into django.contrib.secure and started > work on integrating it with the built-in checks framework as well as > removing some bits of it that have since been added to Django > (frame-deny, SSL-proxy support). > Is it appropriate for this to be a contrib package? That implies it needs to be added to INSTALLED_APPS; I'm not convinced that this is a desirable approach. If django-secure is important enough to include as part of Django's codebase (and I fully agree it is), I'd consider security to be part of core, not something you can opt out of. Including it as django.core.checks.security (or similar) would make more sense to me. Russ %-) -- 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/CAJxq84_Tq1Fnm_pG4pMSy98DOLsnLtVp9jEgTo6X8%2BH%2BJYi1dQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
