Re: Customizable Serialization check-in

[Piotr Grabowski]

Hi,

In the past 3 weeks, my project has changed a lot. First of all I 
changed output of first phase of serialization. Previously it was python 
native datatypes. At some point I added dictionary with metadata to it. 
Metadata was used in second phase of serialization. Now after first 
phase I returned ObjectWithMetadata which is wrapping for python native 
datatypes. It's a bit hackish so I don't know it is good solution:


class ObjectWithMetadata(object):
def __init__(self, obj, metadata=None, fields=None):
self._object = obj
self.metadata = metadata or {}
self.fields = fields or {}

def get_object(self):
return self._object

def __getattribute__(self, attr):
if attr not in ['_object', 'metadata', 'fields', 'get_object']:
return self._object.__getattribute__(attr)
else:
return object.__getattribute__(self, attr)

# there is a few more methods like this (for acting like a 
MutableMapping and Iterabla) and all are similar

def __getitem__(self, key):
return self._object.__getitem__(key)

...

Thanks to this solution, ObjectWithMetadata is acting like object stored 
in _object in almost all cases (also at isinstance tests), and there is 
place for storing additional data.


I didn't change deserialization so in output there are python native 
datatypes without wrapping. I don't know if this is good because there 
is no symmetry in this:
Django object -> python native datatype packed in ObjectWithMetadata -> 
json -> python native datatype -> Django object



I have all dumpsdata formats working now (xml, json, yaml). All tests 
pass, but there is problem with order of fields in yaml. It will be 
fixed soon.
I make new format new_xml which is similar to json and yaml. It's easier 
to parsing it.


Old:

 rel="ManyToOneRel">1
rel="ManyToManyRel">






New:

 
  1
   
   1
   2
   



There is also problem with json and serialization to stream because json 
is using extensions written in C (_json) for performance and this leads 
to exceptions when ObjectWithAttributes is used, so before pass objects 
to json.loads these objects should be unpacked from ObjectWithMetadata.



Probably there is no chance to achieve one of most important requirement 
which I have specify - using only one Serializer to serialize Django 
Models to multiple formats:

serializers.serialize('json', objects, serializer=MySerializer)
serializers.serialize('xml', objects, serializer=MySerializer)

Trouble is with xml (like always ;).  In xml every (model) field must be 
converted to string before serializing in xml serializer. In json and 
yaml if field have protected type (string, int, datetime etc.) then 
nothing is done with it. Converting is done in first phase because only 
there is access to field.value_to_string - field method that is used to 
convert field value to string. It can be override by user so simple 
doing smart_unicode in second phase instead isn't enough.



Most important tasks in TODO:
handling natural keys
tests
x correctness
x performance (I suspect my solution will be worse than actual used 
in Django, but how much?)

documentation

https://github.com/grapo/django/tree/soc2012-serialization/django/core/serializers
--
Piotr Grabowski

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

Hi,

Sorry for the delay in getting back. I was meanwhile working on
centralized tokenization for few days, while still trying to figure
something better for CSRF.

On 03:52 -0400 / 25 Jul, Alex Ogier wrote:
> On Tue, Jul 24, 2012 at 11:37 PM, Rohan Jain  wrote:
> >
> > I had one more idea, "Pluggable CSRF checkers".
> >
> > Currently, the CSRF middleware has two kinds of checks, referer (for
> > https) and secret validation token (common). These with origin header
> > based checker (if we add it) come in conditional blocks, making
> > switching them difficult. So what I propose to do is decouple their
> > logic from CSRF middleware and each of them provide a checker. It goes
> > like this:
> >
> > A setting for configuring global CSRF checkers:
> >
> > CSRF_CHECKERS = {
> > 'django.middleware.csrf.checkers.OriginChecker',
> > # This one can be strict for https and lax for http
> > 'django.middleware.csrf.checkers.RefererChecker',
> > # contrib.sessions could provide a csrf checker maintained
> > # with sessions. This stores the token in session data.
> > 'django.contrib.sessions.csrf_checkers.SessionChecker'
> > }
> >
> 
> I don't think this is a good idea. If you enumerate security features
> in settings.py, then later additions won't be picked up by default. If
> Django add a new CSRF checking mechanism, we want everybody to take
> advantage of it with no modifications.
> 
> Ordinarily I agree with you, explicit is better than implicit.
> However, in the case of security features, I think this is inverted:
> Django sites should be implicitly enrolled in all security mechanisms
> if possible, and should be able to explicitly opt out if necessary.
> Almost everyone should be using every single protection Django offers
> on all their requests, and therefore it should be verbose and
> discouraged to turn off these protections.
>

Hmm, that is a valid point. I can drop the configurable CSRF settings.
But still a modular CSRF checkers might be useful, in which the
checkers are selected dynamically. When sessions app is present, use
sessions checker instead of cookies based CSRF token store. Also we
can have switches which incorporate existing behaviour based on
https/http connection and also origin header checking based on its
presence. I will do a prototype implementation for this to polish and
clarify the idea.


## Centralized Tokenization:

A functioning implementation is up at the [centralize-tokenization][0]
branch on my fork. I have written an [initial documentation][1] for
this too. This is basically a merge with my cleanups and
customizations over the work done in period of [djangocon 2011][2].

[0]: https://github.com/crodjer/django/commits/centralized-tokenization
[1]: https://gist.github.com/2203174#file_tokenization.mkd
[2]: https://github.com/yarko/django/commits/djangocon2011-sec

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket 15754 https://code.djangoproject.com/ticket/15754

[Marcob]

On Monday, August 6, 2012 4:49:12 PM UTC+2, Marcob wrote:
>
> I'd really like to see it in Django 1.5 trunk, and it looks like the only 
> blocking reason are missing tests.
>

Wow, thanks a lot Alex Gaynor! :-)

https://code.djangoproject.com/ticket/15754#comment:7

Ciao.
Marco.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/n-8-6N3hYM0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Ticket 15754 https://code.djangoproject.com/ticket/15754

[Marcob]

In previous Django major releases I used to apply lots of patches (and 
suffer some major headaches :-).
After 1.4 only this little one-liner is left: 
https://code.djangoproject.com/ticket/15754
Leaving it out is impossible for me, as the user experience with some 
custom forms can be painfully slow.
I'd really like to see it in Django 1.5 trunk, and it looks like the only 
blocking reason are missing tests.

Since this is a perfomance improvement, would testing for regressions be 
enough?

Ciao.
Marco.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/upJsYZW15tkJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.