Re: integrating django-secure

2014-08-28 Thread Tim Graham
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 helpfu

Re: Improvement to objects.get_or_create and objects.update_or_create

2014-08-28 Thread Tom Evans
On Wed, Aug 27, 2014 at 10:19 PM, Benjamin Scherrey wrote: > I don't believe the functionality is backwards incompatible at all unless > I'm missing something. The new behavior of automatically selecting the > optimal search field (prioritized by pk first then by any discovered field > marked as u

Re: Improvement to objects.get_or_create and objects.update_or_create

2014-08-28 Thread Babatunde Akinyanmi
On 27 Aug 2014 22:19, "Benjamin Scherrey" wrote: > > > You're right, it wasn't hard to implement as external code as I've already done so. The main reason why I propose it for inclusion into Django's codebase is because the new behavior is actually what I would have expected these two functions t

Re: integrating django-secure

2014-08-28 Thread Tim Graham
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 p

Re: integrating django-secure

2014-08-28 Thread Florian Apolloner
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 Google

Re: integrating django-secure

2014-08-28 Thread Michael Manfre
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 you > can run `manage.py

Re: Improvement to objects.get_or_create and objects.update_or_create

2014-08-28 Thread Collin Anderson
This is a bit magical. It means adding or removing a unique constraint could have additional unintended side effects. -- 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: Improvement to objects.get_or_create and objects.update_or_create

2014-08-28 Thread Benjamin Scherrey
You are. of course, correct Tom. I've never once used it that way but that is the published api/contract as you stated. Possibly it should have insisted that the programmer designate which terms are search terms separate from those which are content only rather than making it optional. But my propo

Re: integrating django-secure

2014-08-28 Thread Carl Meyer
On 08/28/2014 12:45 AM, Yo-Yo Ma wrote: > +1 on basically adding the functionality of checksecure to the default > validation. > > -1 to adding the middleware. This doesn't make sense to me. Half the checks that checksecure performs are related to whether you've turned on functionality from the

Re: integrating django-secure

2014-08-28 Thread Carl Meyer
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 --de

Re: Support byte range requests in django.views.static.serve

2014-08-28 Thread mdj2
I made a ticket in the hopes of drawing more attention to the patch: https://code.djangoproject.com/ticket/23382 On Sunday, April 13, 2014 8:30:37 PM UTC-7, md...@pdx.edu wrote: > > Is the Django community interested in supporting HTTP range requests in > django.views.static.serve >

Re: integrating django-secure

2014-08-28 Thread Tim Graham
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 hav