Re: Customizable Serialization check-in
On Sat, May 5, 2012 at 4:08 AM, Piotr Grabowski wrote: > Hi, > > During this week I have a lot of work so I didn't manage to present my > revised proposal in Monday like i said. Sorry. I have it now: > https://gist.github.com/2597306 Hi Piotr, At a high level, I think you're headed in the right direction. I like the way you've separated Field and Serializer, and I like the way that Serializer represents on "nesting level" of the final output (so if you want complex formats for a single object, such as with the way Django's JSON serializer has id, model and fields at the top level, you nest Serializers to suit). Here's some specific feedback: * I can see that ModelSerializer will play an important part in your proposal. However, some of your API proposals seem a little unnecessary -- or are unclear why they're needed. Some areas that need clarification: - I'm not sure I follow how class_name would be used in practice. The act of deserialization is to take a block of data, and process it to populate an object. In the simplest case, you could provide an empty instance (or factory) that is then populated by deserialization. In this case, no class name is required -- it's provided explicitly by the object you provide. A more complex case is to use the data itself to determine the type of object to create. This seems to be the reason you have "class_name", but I'm not sure it's that simple. Consider a case where you're deserializing a thing of objects; if the data has a "name" attribute, create a "Person" object, otherwise create a "Thing" object. The object required is well defined, but not neatly available in a field. There's also no requirement that deserialization into an object is handled by a ModelSerializer. ModelSerializer should just be a convenient factory for populating a Serializer based on attributes of a model -- so anything you do with ModelSerializer should be possible to do manually with a Serializer. If class_name is tied to ModelSerializer, we lose this ability. - I'm not sure I see the purpose of "aliases" -- or, why this role can't be played by other parts of the system. In particular, I see Field() as a definition for how to fill out one 'piece' of a serialised object. Why doesn't Field() contain the logic for how to extract it's value from the underlying object? - Why is preserve_field_ordering needed? Can't ordering be handled by the explicit order of field definitions, or the ordering in the "fields" attribute? * As a matter of style, serializer_field_value and deserialize_field_value seem excessively long as names. Is there something wrong with serialize and deserialize? * I don't think getattr() works quite how you think it does. In particular, I don't think: getattr(instance, instance_field_name) = getattr(obj, field_name) will do what you think it does. I think you're looking for setattr() here. * Can you elaborate some more on the XML attribute syntax in your proposal? One of your original statements (that I agree with) is that the "format" is independent of the syntax, and that a single set of formatting rules should be able to be used for XML or for JSON. The big difference between XML and JSON is that XML allows for values to be packed as attributes. I can see that you've got an 'attribute' argument on a Field, but it isn't clear to me how JSON would interpret this, or how XML would interpret: - A Field that had multiple sub-Fields, all of which were attribute=True - A Field that had multiple sub-Fields, several of which were attribute=False - The difference between these two definitions by your formatting rules: subval main value In particular, why is the top level structure of the JSON serializer handled with nested Serializers, but the structure of the XML serializer is handled with nested Fields? > Next week I hope there will be some discussion about my proposal. I will > also think how it should be done under the hood. There should be some > internal API. I should also resolve one Django ticket. I think about this > https://code.djangoproject.com/ticket/9279 There will be good for test cases > in my future solution. I would suggest that you don't spend *too* much time on this. It's certainly a good idea to get to know our committing procedures, and historically we've encouraged students to get to use working on a small ticket as a way to do this. However, your project is unusual in that you've been accepted without a firm API proposal. Given that you won't really be able to work on the GSoC without an accepted proposal, I'd suggest that your API should take precedence in your pre-GSoC plans. > I should write my proposal on this group? In github I have nice formatting > and in this group my Python code was badly formatted. It's up to you; however, the problem with posting to a Gist (or similar) is that it's very hard to comment on specific parts of your proposal. I know code formatting is a pain in Google groups, but it is a much be
Re: startproject template context
Ok, thanks. Will open one now. On Tuesday, May 1, 2012 4:58:16 PM UTC-5, Ramiro Morales wrote: > > On Tue, May 1, 2012 at 11:04 AM, Sam Simmons > wrote: > > For app/project templates I found the docs a little misleading when they > say > > 'Any option passed to the startapp command' will be added to the > context. > > You' ve understood the documentation correctly. This is a feature that is > currently (and AFAICT was DOA) not fully implemented because there is code > to > process and add the custom command line switches to the context but the > validation that the management commands framework performs on the command > line > options isn't allowing them to pass. > > Please open a ticket in our issue tracker. > > Thanks. > > -- > Ramiro Morales > -- 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/-/vptAIAgj1JAJ. 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.
Name of the "main" app in a template-based project
Another question about the project template command : In the example source of django, the name of the "main app" folder in the root project folder is named "project_name" so to be catched by the context rendering, I suppose. I tried to change this default name I want, but the resulting project contains a name like "project-name-template-66b7f02" My question is : is it mandatory in django 1.4 new folder structure that this first app has the same name as the project ? Motivation : I have references to this "main app" models in other packaged apps, so I need this "main app" to have a fixed name, whereas the project folder name is rather the name of this particular django instance. Thanks for your help -- 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/-/7BvjQmjPHxsJ. 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: startproject template context
Here it is for future reference: https://code.djangoproject.com/ticket/18277 On Tuesday, May 1, 2012 4:58:16 PM UTC-5, Ramiro Morales wrote: > > On Tue, May 1, 2012 at 11:04 AM, Sam Simmons > wrote: > > For app/project templates I found the docs a little misleading when they > say > > 'Any option passed to the startapp command' will be added to the > context. > > You' ve understood the documentation correctly. This is a feature that is > currently (and AFAICT was DOA) not fully implemented because there is code > to > process and add the custom command line switches to the context but the > validation that the management commands framework performs on the command > line > options isn't allowing them to pass. > > Please open a ticket in our issue tracker. > > Thanks. > > -- > Ramiro Morales > -- 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/-/3bdweBGlnZoJ. 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
Hi,
Last week I looked into the Ticket [#18194][0]:
- Trivial attempts to handle the issue.
- Wrote a minor initial patch.
- The test fails for Cache and Cookie backend.
Also, I looked at the talks from Paul regarding advanced security
topics at py/django cons. Realised that why I should not attempt
anything related to encryption in my project.
There is high academic pressure currently, so I am not able to give
enough time to these. I think the situation will be better this
weekend onwards.
I'll try to work on:
- Write tests which emulate the problem in #18194 well, and then work
on the final fix.
- Start looking into resources useful for my project, like [The
Tangled Web][1].
Rohan Jain
[0]: https://code.djangoproject.com/ticket/18194
[1]: http://www.amazon.com/The-Tangled-Web-Securing-Applications/dp/1593273886
On Fri, Apr 27, 2012 at 6:54 PM, Rohan Jain wrote:
> Hi,
>
> I am Rohan Jain, a student from Indian Institute of Technology,
> Kharagpur. I'll be doing a Google Summer of Code project with django
> this year under the title "Security Enhancements". As the title
> suggests, it has something to do with Security Enhancements: like
> improvements in CSRF protection and tokenization.
>
> I have made some small updates to the proposal with the feedback it
> got. It is under VC over here: http://gist.github.com/2203174
> There isn't a direct way to diff gists, so here are the changes I did
> if somebody has already read the proposal:
>
> - The origin check will be an additional step to ensure a valid
> request and not standalone. The conventional checks will still
> exist.
>
> - Add some issues Luke pointed out about signing and using sessions.
>
> - Add info about my github fork and branches.
>
> What I will be doing the following week:
>
> - I haven't done any major contribution to django yet apart from a
> tiny ticket some time ago. So, I'll be working on an ticket next
> few weeks. It is related to filesystem backend of contrib.sessions,
> was raised some time ago:
> https://code.djangoproject.com/ticket/18194
>
> - Cleanup and organize the proposal a bit more (Probably start
> tracking it as the CSRF protection page -
> https://code.djangoproject.com/wiki/CsrfProtection)
>
> (I have also appended the current proposal below in this post)
>
> --
> Rohan
>
>
> Proposal
>
>
> #Abstract
>
> Django is a reasonably secure framework. It provides an API and
> development patterns which transparently take care of the common web
> security issues. But still there are security features which need
> attention. I propose to work and improved CSRF checking without any
> compromises and on integration of existing work on centralized token
> system. If time permits I will also attempt on integration of
> django-secure.
>
> #Description
> ##CSRF Improvements
>
> Cross-Origin Resource Sharing (CORS):
> W3C has a working draft regarding [CORS][w3c-cors-draft], which opens
> up the possibility for allowing client-side request cross-origin
> requests. This directly triggers in mind the capability to develop
> API which can be exposed directly to the web browser. This would let
> us get rid of proxies and other hacks used to achieve this.
> Currently all the major browsers support this: Chrome (all versions),
> Firefox (> 3.0), IE (> 7.0), Safari (> 3.2), Opera (> 12.0). Firefox
> and Chrome send the origin header for both AJAX and standard from POST
> requests. Introduced it here as some further parts of the post refer
> to this.
>
> ###Origin checking
>
> With CORS around need for using CSRF token can be dropped, at least in
> some browsers. [Ticket #16859][orig-check-ticket], is an attempt for
> that. But this was rejected because of neglecting the case for
> presence of `CSRF_COOKE_DOMAIN` (Refer to the closing comment on the
> ticket for details). So to handle this we need to simulate checking of
> CSRF cookie domain as web browsers do it. Maybe:
>
> ```python
>
> reqest.META.get('HTTP_ORIGIN').endswith(settings.CSRF_COOKIE_DOMAIN)
>
> ```
>
> In case the server receives an origin header in the request, it will
> be used for an initial checking and then all the conventional checks
> will be done. The general security will automatically be improved with
> the increased market share of newer browsers which support Origin
> Header.
>
> As the closing comment points it out, we can't do this with secure
> requests. They need to be essentially checked against the referrer or
> origin, at least for now. We can not be sure that some untrusted or
> insecure subdomain has not already set the cookie or cookie domain.
> To deal with this, we have to consider https separately as it is
> being done now. So it will be something like:
>
> ```python
> def process_view(self, request, ):
>
> # Same initial setup
>
> if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
>
> host = request.get_host()
> origin = reqest.META.get('HTTP_ORIGIN', "")
> cooki
