Re: Django 1.7 data migrations?
Andrew Godwin <and...@aeracode.org> writes: > Hi Kent, > > The documentation is not yet complete, hence your confusion. There is > indeed provision for data migrations in the new system, with an > operation called RunPython - I'll see if I can get documentation up > for it this week. OK, splendid! :-) I guess I was fooled by the polished look of that incomplete page. Thanks for all your work on South --- you've saved me a lot of time and tears over the years! / Kent Engström, Lysator -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/m31tza936l.fsf%40lysator.liu.se. For more options, visit https://groups.google.com/groups/opt_out.
Django 1.7 data migrations?
I just had a look at the Django 1.7 migrations docs at https://docs.djangoproject.com/en/dev/topics/migrations/ In South, I've learned to use schema migrations and data migrations together, for situations like when you need to combine two fields, or split them (schema migration to add new fields, data migration to copy data, schema migration to remove old fields). Is the new built-in system supposed to handle data migrations too? Is so, how? I did not find a documented place to put arbitrary Python code in the new declarative format. If not: how is that need handled in the future? Migrate to point X, run a script, continue to migrate? Should this be mentioned somewhere in the docs? Sorry if I'm confused about this, / Kent Engström, Lysator -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/m3d2iupyp7.fsf%40lysator.liu.se. For more options, visit https://groups.google.com/groups/opt_out.
Re: CSRF protection and cookies
Paul McMillan <p...@mcmillan.ws> writes: > In the meantime, if you use SSL on each of your subdomains, you get > strict checking of the Referer header for CSRF, which mitigates that > particular avenue of attack. Since you're using sessions and auth, you > should be using SSL, and so the protection is mostly free. Of course. The sites I'm thinking of are HTTPS only. I had forgot about the Referer header check. It seems that it would stop the subdomain-to-subdomain CSRF attacks as long as the site is only using HTTPS, wouldn't it? Thanks for your work on this, / Kent Engström -- 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: CSRF protection and cookies
Paul, thanks for your reply! Comments inline: Paul McMillan <p...@mcmillan.ws> writes: >> Would it not be possible to move the second instance of the nonce (that >> will be compared to the form field) from a cookie to a session variable >> (at least when a session is available)? Would that result in other >> problems instead? > > Yes it's possible, and that's how our CSRF protection worked at first. > However, it has the disadvantage of being tied to sessions, and so our > last revision of the framework specifically decoupled the two. > One reason you may not want it tied to sessions is if you have a > public comment form on an unencrypted page, but also want to have > SESSION_COOKIE_SECURE, so sessions are never sent unencrypted. Another > is that the extra session lookup for every form submitted may be a > performance problem, depending on how you store your sessions and what > your traffic profile looks like. Another reason is that you may not be > using the sessions framework at all, and still want forms with CSRF > protection. The applications I have in mind (where the "subdomain can set cookies for other subdomains" could hurt) use django.contrib.auth and thus sessions as well. Thus, they already have to do a session lookup for the auth check, haven't they? Could that be reused for the CSRF check? I think it would be OK to have to specify something like a SessionBasedCsrfMiddleware instead of the normal CsrfMiddleware, if the choice between "session" and "cookie" cannot be made dynamically by the framework. Just so I am not missing a class of attacks here: how important is CSRF protection for non-session applications? I have always viewed CSRF chiefly as an attack where you try to fool somebody who is authenticated (and therefore has privileges in the system) to ask the system to do a bad thing by doing the cross-site POST. > Improving the CSRF in this fashion is on my list of things to do, but > it's a bit of a tricky problem, and so it hasn't happened yet. We can > do better than we do now, but not without somewhat changing the > properties of the system. If you would like help with testing etc for this, I hope I can offer some time. BTW, should I submit a ticket about this to the Django ticket database or is there a more general ticket that already covers this? / Kent Engström -- 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.
CSRF protection and cookies
Hi, > Today we've released Django 1.3.1 and Django 1.2.6 to deal with > several security issues reported to us. Details of these issues and > the releases, along with several important advisory notes, are > available in the blog post on djangoproject.com: > > https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/ I've been thinking about the problems caused by the CSRF cookies being settable by other servers sharing the same domain name, as mentioned at the URL above: > Advisory: Cross-subdomain CSRF attacks > > Due to the nature of HTTP cookies, a cookie can be set from a subdomain > which will be valid for the entire domain. This means that an attacker > who controls a subdomain can, for example, set a CSRF cookie which will > be valid for the entire domain. If I understand it correctly, our CSRF protection works by putting the same random nonce in a form field and a cookie. The protection comes from the fact that the bad guy can only control the form field but not the cookie. But in the case above, he can control the cookie too and the protection fails. Is that correct? Would it not be possible to move the second instance of the nonce (that will be compared to the form field) from a cookie to a session variable (at least when a session is available)? Would that result in other problems instead? / Kent Engström -- 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.
