Re: GSoC Check-in: Security Enhancements

2012-06-12 Thread Rohan Jain
I have done some work on CSRF revolving around origin header checking. The origin header is fairly new and is not yet implemented in a uniform fashion in the major browsers, so it cannot be solely relied upon for CSRF checks. Instead we check if the header exists and use it only for rejection of

Re: json vs simplejson

2012-06-12 Thread Vinay Sajip
On Jun 11, 10:51 pm, Luke Plant wrote: > We've switched internally from json to simplejson. Our 1.5 release notes > say: Do you mean the other way around? > You can safely change any use of django.utils.simplejson to json > > I just found a very big difference between

Re: json vs simplejson

2012-06-12 Thread Luke Plant
On 12/06/12 06:14, Alex Ogier wrote: > This seemed strange to me because the standard library json shipping > with python 2.7.3 is in fact simplejson 2.0.9, so I did some digging. > It turns out that if the C extensions have been compiled and you pass > a str instance to loads(), then you get

Re: json vs simplejson

2012-06-12 Thread Luke Plant
On 12/06/12 10:58, Vinay Sajip wrote: > > I'm not sure there's any easy way out, other than comprehensive > testing. There is another issue I found. Django's DateTimeAwareJSONEncoder now subclasses json.JSONEncoder instead of simplejson.JSONEncoder. The two are not perfectly compatible.

Re: json vs simplejson

2012-06-12 Thread Alex Ogier
On Jun 12, 2012 6:54 AM, "Luke Plant" wrote: > I've found the same difference of behaviour on both a production machine > where I'm running my app (CentOS machine, using a virtualenv, Python > 2.7.3), and locally on my dev machine which is currently running Debian, > using

Re: json vs simplejson

2012-06-12 Thread Alex Ogier
On Tue, Jun 12, 2012 at 7:19 AM, Luke Plant wrote: > > There is another issue I found. > > Django's DateTimeAwareJSONEncoder now subclasses json.JSONEncoder > instead of simplejson.JSONEncoder. The two are not perfectly compatible. > simplejson.dumps() passes the keyword

Re: json vs simplejson

2012-06-12 Thread Luke Plant
On 12/06/12 13:28, Alex Ogier wrote: > Wait, 'import simplejson' works? Then that explains your problems. You > are using a library you installed yourself that has C extensions, > instead of the system json. If you switch to a system without > simplejson installed, then you should see the

Re: json vs simplejson

2012-06-12 Thread Alex Ogier
On Tue, Jun 12, 2012 at 8:49 AM, Luke Plant wrote: > > I agree my existing program had a bug. I had simplejson installed > because a dependency pulled it in (which means it can be difficult to > get rid of). > > The thing I was flagging up was that the release notes say

ModelForms and the Rails input handling vulnerability

2012-06-12 Thread Luke Plant
Hi all, On django-core we've been discussing an issue that was security related. However, we decided it wasn't urgent enough to warrant a security release, and so we're moving the discussion here (especially because we couldn't agree on what to do). For the record, I brought up the issue

Re: ModelForms and the Rails input handling vulnerability

2012-06-12 Thread Alex Ogier
On Tue, Jun 12, 2012 at 7:16 PM, Luke Plant wrote: > Hi all, > > On django-core we've been discussing an issue that was security related. > However, we decided it wasn't urgent enough to warrant a security > release, and so we're moving the discussion here (especially

Re: ModelForms and the Rails input handling vulnerability

2012-06-12 Thread Karen Tracey
On Tue, Jun 12, 2012 at 10:10 PM, Alex Ogier wrote: > No one can sneak extra unexpected fields past a developer by editing HTML > client side, because if the field wasn't rendered to HTML it's not > going to validate. > But it may. If you have a template which renders

Re: ModelForms and the Rails input handling vulnerability

2012-06-12 Thread Gary Reynolds
On 13 June 2012 09:16, Luke Plant wrote: > = Option 2: Deprecate Meta.exclude, but still allow a missing > Meta.fields attribute to indicate that all fields should be editable. > > The policy here is essentially this: if any fields the model are > sensitive, assume all are

Re: ModelForms and the Rails input handling vulnerability

2012-06-12 Thread Alex Ogier
On Tue, Jun 12, 2012 at 11:43 PM, Karen Tracey wrote: > On Tue, Jun 12, 2012 at 10:10 PM, Alex Ogier wrote: >> >> No one can sneak extra unexpected fields past a developer by editing HTML >> client side, because if the field wasn't rendered to HTML it's