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
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
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
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.
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo