On Friday, September 20, 2013 4:40:39 PM UTC+2, Curtis Maloney wrote:
> I talked with the OP [or someone who talks a _lot_ like the OP:)]
>
Oh, I should meet this animal–pardon, this guy. :)
And the answer is: there's no way for a matching Decoder to know when to
> decode any of these types, si
On Friday, September 20, 2013 3:59:47 PM UTC+2, Donald Stufft wrote:
>
> A basic tenant in securing systems is that you make each piece of the
> system responsible for it's own security and you don't have it depend on
> the security of another system. Moving away from pickle as the default
> se
On Friday, September 20, 2013 4:40:39 PM UTC+2, Curtis Maloney wrote:
>
> And the answer is: there's no way for a matching Decoder to know when to
> decode any of these types, since there's no schema available.
>
Good point, it would be doable by serializing into something like '{_type:
dateti
ango/core/serializers/json.py#L79
>
Ok, I though as much, but wanted to be sure.
It's either to change the default to PickleSerializer
>
Most likely not gonna happen since we choose secure by default.
or to mitigate the JSONSerializer issue supporting these data types:
>
>-
I talked with the OP [or someone who talks a _lot_ like the OP:)] on IRC
about this issue before recommending they open a ticket... and aside from
anything else discussed, since someone already saw fit to include an
extended JSONEncoder class in core/serializers, why doesn't the session
machinery r
On Sep 20, 2013, at 9:52 AM, Davide Rizzo wrote:
> The examples you mentioned (forms, admin) were significant improvements
> themselves, with big benefits to Django users. Switching the default session
> serializer to JSONSerializer is providing no benefit to any user. It's
> addressing a sec
r
SESSION_COOKIE_HTTPONLY and SESSION_COOKIE_SECURE settings?).
I don't want to lose focus on my proposal. It's either to change the
default to PickleSerializer or to mitigate the JSONSerializer issue
supporting these data types:
- datetime, timedelta objects (supported by DjangoJ
On Friday, September 20, 2013 10:24:00 AM UTC+2, Davide Rizzo wrote:
>
> - using the raw JSONEncoder by default is not offering any significant
> security advantage over using an extended encoder. I feel like it's going
> to discourage coders to use JSONSerializer at all.
>
Btw could it be tha
hoice, it becomes
>> inconvenient as the JSON encoder used by JSONSerializer is not the same
>> used elsewhere in Django, as it only support basic data types: string,
>> int/floats, booleans, nested dicts and lists, None.
>>
>> The inconvenience is breaking compa
in
> cookies.
>
> While this can be considered a sensible security choice, it becomes
> inconvenient as the JSON encoder used by JSONSerializer is not the same
> used elsewhere in Django, as it only support basic data types: string,
> int/floats, booleans, nested dicts and lists, None
Hi Davide,
On Thursday, September 19, 2013 4:46:44 PM UTC+2, Davide Rizzo wrote:
>
> The inconvenience is breaking compatibility with all third party apps that
> rely on storing extended data types (such as those supported by
> DjangoJSONEncoder) with the default settings. Properly
red in
cookies.
While this can be considered a sensible security choice, it becomes
inconvenient as the JSON encoder used by JSONSerializer is not the same
used elsewhere in Django, as it only support basic data types: string,
int/floats, booleans, nested dicts and lists, None.
The inconvenie
lready in place.
Basically, you'd just keep the basic data types (CharField, TextField,
Boolean, DateTime, etc) but remove fields like EmailField and such from
the backends and redefine them in the Field.get_internal_type as a
CharField with a maxlength of 75. Just browsing through some of the
bac
>This immediately breaks if you extend a field and don't implement that
>method. Preferably, all the Field classes would implement the mapping
>right there. Each database shouldn't need to know how to map a USState
>field for example, just strings, dates and integers, etc.
Can't work. The field
# This immediately breaks if you extend a field and don't implement
# that method. Preferably, all the Field classes would implement the
# mapping right there. Each database shouldn't need to know how to
# map a USState field for example, just strings, dates and integers,
# etc.
But, should eac
I think we're in agreement. The inelegance was just that all the
builtin Field classes's get_internal_type() just returned
self.__class__.__name__ and expected the database backends to know map
each of those class names.
This immediately breaks if you extend a field and don't implement that
meth
On 11/15/05, Kevin <[EMAIL PROTECTED]> wrote:
> I'm a bit concerned that the DATA_TYPES are hard-coded in the database
> backends. I think it would preferrable (and more maintainable/robust)
> to try to define a generic abstract list of data types that match well
> with
I'm a bit concerned that the DATA_TYPES are hard-coded in the database
backends. I think it would preferrable (and more maintainable/robust)
to try to define a generic abstract list of data types that match well
with the sql variants (text, boolean, integer, etc) instead of directly
definin
18 matches
Mail list logo
