I am asking for directions about what to do about
django.db.models.sql.query (actually sql.*). I would like to refactor
the code in small incremental steps. However, this will bring internal
API breakages, and will likely add some more bugs temporarily.
While the ORM mostly works, it IMHO needs so
On 13 kesä, 02:16, Luke Plant wrote:
> For the record, I brought up the issue initially, and favour the most
> secure of the options outlined below, but I'll try to summarise with as
> little bias as I can!
> = Option 1: Leave things as they are, just document the problem. This
> was the least po
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 not
>> going to validate.
>
>
> But it may.
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 potentially, and requir
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 specific fields, and yet
th
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 because we
> couldn't agree o
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 initiall
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 "You can
> safely change an
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 "proper"
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 argument 'namedtuple_as_ob
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 the Debian Python 2.7.2
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.
simplejs
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 that
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 json and simplejson
>
> >
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
15 matches
Mail list logo
