Re: Deprecate FCGI support in Django 1.7

Let me second the need for a good "How To" document on deployment. As a neophyte django user I suddenly felt very lost last week. After several months of development, the ADO interface to the Microsoft SQL server from Linux is working (it still needs some tuning, but the data does go in and ou

Re: Change username field widget in AuthenticationForm based on USERNAME_FIELD

On Mon, Aug 5, 2013 at 10:00 PM, ptone wrote: > This seems like a reasonable change. I don't love the fact that the > contrib.auth built in forms quasi support custom user models, as it leads > to a less clear delineation about what parts of contrib.auth are tightly > coupled auth the default Use

Re: Deprecate FCGI support in Django 1.7

On Tue, Aug 6, 2013 at 6:28 AM, VernonCole wrote: > I had come the the conclusion that FastCGI was the only way behind NginX, the best two options seem to be uWSGI and gunicorn. personally, I like uWSGI, but both are quite performant and low-resource. -- Javier -- You received this message b

Re: Deprecate FCGI support in Django 1.7

On Tue, Aug 6, 2013 at 10:18 AM, Javier Guerra Giraldez wrote: > On Tue, Aug 6, 2013 at 6:28 AM, VernonCole wrote: > > I had come the the conclusion that FastCGI was the only way > > > behind NginX, the best two options seem to be uWSGI and gunicorn. > personally, I like uWSGI, but both are quite

Security Advisory: BREACH and Django

Hi folks -- At last week's Black Hat conference, researchers announced the BREACH attack (http://breachattack.com/), a new attack on web apps that can recover data even when secured with SSL connections. Given what we know so far, we believe that BREACH may be used to compromise Django's CSRF prot

Re: Deprecate FCGI support in Django 1.7

On Tue, Aug 6, 2013 at 9:40 AM, Andre Terra wrote: > Assuming a UNIX environment. In Windowsland, nginx is still one of the best > alternatives. I meant use those _behind_ NginX. neither is really good as an external-facing HTTP process. -- Javier -- You received this message because you ar

Re: Security Advisory: BREACH and Django

On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss wrote: > > We plan to take steps to address BREACH in Django itself, but in the > meantime we recommend that all users of Django understand this > vulnerability and take action if appropriate. > > Would randomizing the CSRF token on

Re: Security Advisory: BREACH and Django

This is a fascinating attack. I scanned all of the information that I could find and it wasn't clear how this could be used to breach CSRF protection. Is there more detail somewhere on that specific attack vector? -Rob On Tuesday, August 6, 2013 10:42:01 AM UTC-4, Jacob Kaplan-Moss wrote:

Re: Security Advisory: BREACH and Django

On Aug 6, 2013, at 12:16 PM, Tom Scrace wrote: > On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss wrote: > > We plan to take steps to address BREACH in Django itself, but in the meantime > we recommend that all users of Django understand this vulnerability and take > action if a

Re: Security Advisory: BREACH and Django

On Aug 6, 2013, at 12:45 PM, Rob Yates wrote: > This is a fascinating attack. I scanned all of the information that I could > find and it wasn't clear how this could be used to breach CSRF protection. > Is there more detail somewhere on that specific attack vector? Essentially if you hav

Re: Security Advisory: BREACH and Django

Since the 1.6 release is very close, what are the chances that the security fix would get backported to Django 1.4.x, even if 1.6 lands before a fix is backported? There was a blog post about extending support for 1.4, but I don't remember seeing any discussion on the list to help "figure out the s

Re: Security Advisory: BREACH and Django

Am I correct that it is still safe to have compression enabled for static files? Assuming you're not sending secrets inside CSS or JS files? http://wiki.nginx.org/HttpGzipModule says that the gzip on directive can be set in location. On Tuesday, 6 August 2013 17:58:42 UTC+1, Donald Stufft wro

Re: Security Advisory: BREACH and Django

On Aug 6, 2013, at 1:28 PM, mac...@framestart.com wrote: > Am I correct that it is still safe to have compression enabled for static > files? Assuming you're not sending secrets inside CSS or JS files? > > http://wiki.nginx.org/HttpGzipModule says that the gzip on directive can be > set in loc

Re: Security Advisory: BREACH and Django

On 2013-08-06 12:53, Donald Stufft wrote: > On Aug 6, 2013, at 12:16 PM, Tom Scrace wrote: >> On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss >> wrote: >> >> We plan to take steps to address BREACH in Django itself, but in >> the meantime we recommend that all users of Django under

Re: [GSoC] Revamping validation framework and merging django-secure once again

I'm still working at polishing after reviewing. I've deprecated `requires_model_validation` and `validate`. I've started at adding tests for contenttype fields: `GenericForeignKey` and `GenericRelation`. I've updated gsoc2013-checks-review branch [1]. Now it's the same as gsoc2013-checks branch [2

django.utils.functional.cached_property

Is there any reason why django.utils.functional.cached_property should not be documented, so that it can easily be used? I'd have a lot of use for it. Daniele -- You received this message because you are subscribed to the Google Groups "Django de

Re: Security Advisory: BREACH and Django

On 6 Aug 2013, at 12:34 PM, Tim Chase wrote: > On 2013-08-06 12:53, Donald Stufft wrote: >> This incurs the cost that every request to Django invalidates all >> existing CSRF tokens [] OR requires you to store a separate CSRF token >> for each >> request and look up the submitted CSRF token in

Re: [GSoC] Revamping validation framework and merging django-secure once again

On Wed, Aug 7, 2013 at 4:03 AM, Christopher Medrela wrote: > I'm still working at polishing after reviewing. I've deprecated > `requires_model_validation` and `validate`. I've started at adding tests > for > contenttype fields: `GenericForeignKey` and `GenericRelation`. > > I've updated gsoc2013-

Re: Security Advisory: BREACH and Django

How about requiring that if csrfmiddlewaretoken is set, no matter what http method (GET, POST...), it is correct otherwise 403 response. Simon -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receivi