Re: docs.djangoproject.com very slow
Hi, should be back to normal by now. On Monday, July 29, 2013 7:46:20 PM UTC+2, Kevin Veroneau wrote: > > Not sure where to report this, but the docs.djangoproject.com is going > very slow today, and I received a "504 Gateway Time-out" from the nginx > server. Any ideas? > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
docs.djangoproject.com very slow
Not sure where to report this, but the docs.djangoproject.com is going very slow today, and I received a "504 Gateway Time-out" from the nginx server. Any ideas? -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: Modifying the CSRF protection scheme
Hi (quotation below edited) On Monday 29 July 2013 17:59:53 Matthew Lauber wrote: > On Sat, Jul 27, 2013 at 7:12 PM, Shai Berger wrote: > > > > a) Use a signed cookie for csrftoken -- using Django's existing signing > > facility[4], this means signing the cookie with the SECRET_KEY from the > > settings; so that an attacker cannot set arbitrary cookies, and changing > > the SECRET_KEY after a compromise immeiately invalidates csrftoken > > cookies. > > > > b) Optionally allowing time-limited CSRF tokens. Such tokens will be > > generated by adding a parameter of maximum age to the csrftoken tag, and > > by marking view methods (specifically with a decorator, or globally with a > > setting) as requiring timed tokens. When this is used, the posted token > > value will need to be different from the cookie value -- to keep advantage > > 2, the cookie will still be constant, and expiry time will only be present > > in the submitted token[5]. This method breaks the current way we do > > CSRF-protected AJAX, so it will likely stay optional (and opt-in). > > As I understand (a), it sounds like an excellent scheme, and something that > would be simple to update behind the scenes without unduly affecting > application code. I'm more ambivalent about (b). Have you or anyone else > started work on a patch/pull-request for this? > Not that I'm aware of, but (a) is not a new idea, so there may be something out there. Either way, I do not intend to force code-changes on any user with this. Shai. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: Modifying the CSRF protection scheme
As I understand (a), it sounds like an excellent scheme, and something that would be simple to update behind the scenes without unduly affecting application code. I'm more ambivalent about (b). Have you or anyone else started work on a patch/pull-request for this? On Sat, Jul 27, 2013 at 7:12 PM, Shai Berger wrote: > Hi everybody, > > TL;DR: A simple change can make Django's CSRF protection a little better; > an > additional, slightly less simple one, can also make it look better. > > Django's CSRF protection scheme is a bit unusual; unlike most such > schemes, it > does not rely on a value stored in the server that needs to be matched by a > submitted token and is replaced with every submission, but rather on a > constant value stored in a cookie. This generally works (for details of how > and under what conditions exactly, see [1]), but has two minor problems: > > 1) It is unusual, and in particular diverges from what OWASP[2] > recommends[3]; > as a result, security analysts often think it is not secure. They have been > proven wrong in all cases members of core are aware of, but proving it > again > and again is a nuisance, and there may be bad PR related to this. > > 2) It carries a "second-order" vulnerability: If your site has been > compromised (XSS, Man-in-the-middle, or server compromise) then you become > persistently vulnerable to CSRF. All of these vulnerabilities are way worse > than CSRF and render all CSRF protection schemes worthless while they last; > the point is *not* that they allow CSRF, but rather that they allow CSRF > to be > performed after the main hole has been plugged. This is because the > attacker > can use the main vulnerability to "steal", or even set, csrftoken cookie > values, which they can then use later. After a successful attack of this > magnitude, you need to reset the csrftoken cookies of all users, and this > is > neither obvious nor straightforward to do. > > Django's unique scheme does have two advantages over the more common > solutions, which we would like to keep: > > 1) It is not tied to sessions, users, or site-stored per-user data, > allowing > CSRF protection to a wider range of users > > 2) It avoids the problem of having only one "current" token, which causes > the > submission of one form to invalidate forms open in other browser tabs. > > To improve on both problem issues, while keeping the advantages, I suggest > the > following modifications: > > a) Use a signed cookie for csrftoken -- using Django's existing signing > facility[4], this means signing the cookie with the SECRET_KEY from the > settings; so that an attacker cannot set arbitrary cookies, and changing > the > SECRET_KEY after a compromise immeiately invalidates csrftoken cookies. > > b) Optionally allowing time-limited CSRF tokens. Such tokens will be > generated > by adding a parameter of maximum age to the csrftoken tag, and by marking > view > methods (specifically with a decorator, or globally with a setting) as > requiring timed tokens. When this is used, the posted token value will > need to > be different from the cookie value -- to keep advantage 2, the cookie will > still be constant, and expiry time will only be present in the submitted > token[5]. This method breaks the current way we do CSRF-protected AJAX, so > it > will likely stay optional (and opt-in). > > As you may guess, signing the cookie adds an actual iota of security. > Adding > expiry adds very little -- if an attacker has access to the cookie, they > can > usually just ask the site to generate valid tokens for them, so getting any > real protection will require annoyingly short expiry times. But the fact > that > an attacker needs this extra step makes it a tiny bit harder for them and > makes their actions a tiny bit more detectable; and having a constantly- > changing CSRF token may make the whole thing look a little better to naive > analysts. > > I had some help and guidance in drafting this proposal -- you can credit > Donald Stufft, mostly, for any egregious blunder I didn't make. I am still > responsible for the ones I did make. > > Your comments are welcome, > > Shai. > > > [1] https://docs.djangoproject.com/en/dev/ref/contrib/csrf/ -- in > particular, > "how it works" and "limitations" > > [2] https://www.owasp.org > > [3] > https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet > > [4] https://docs.djangoproject.com/en/dev/topics/signing/ > > [5] django.core.signing.TimestampSigner signs content with the time of the > signature, and then takes a max_age in its unsign() method; the suggested > method would go the other way around, timestamping the token with the time > of > expiry, to allow checking without using data stored on the server (and to > allow different forms to use different max-age values). > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and s
Re: Streaming sitemaps
But then it still makes it better on the Python side. You still have psycopg memory problems but don't you have that now all the time anyways? On Friday, July 26, 2013 11:50:57 AM UTC+2, Aymeric Augustin wrote: > > On 26 juil. 2013, at 09:40, julianb > > wrote: > > > I don't think the queryset needs to be loaded into memory. There is an > iterator() method available: > > I don't think .iterator() does what you expect. See > http://thebuild.com/presentations/unbreaking-django.pdf, slide 62 and 63. > If you're careful, model instances will be garbage-collected, but you still > have the entire psycopg result set in memory. > > To improve performance in this case you're probably better off with > .values() or .values_list(), or more likely by splitting your sitemap. > > -- > Aymeric. > > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] django-localflavor 1.0 release
Hi all, As proposed two months ago [1], I just released django-localflavor 1.0 with all "local flavors" recombined. This fixes the failed handover of the django.contrib.localflavor app to the broader community with the per-country django-localflavor-* apps before the Django 1.5 release. Those packages are now all integrated again in the new django-localflavor app. All contributors of the now defunct per-country apps have been given commit access to the new app. The main purpose of the new app is to reduce maintenance friction of 40+ separate "localflavors". Releases of django-localflavor are independent from Django's release cycle but will always support the currently maintained Django releases. It currently supports Python 2.6, 2.7, 3.2 and 3.3 and runs on Django 1.5.x and the upcoming 1.6.x. Here's the source code of django-localflavor: https://github.com/django/django-localflavor The documentation: https://django-localflavor.readthedocs.org/ Translations can be updated on Transifex: https://www.transifex.com/projects/p/django-localflavor/ And the tests are hosted on Travis CI (a tox config also exists): https://travis-ci.org/django/django-localflavor Thanks for the attention, please let me know if you have any questions :) Jannis PS: In case pip installing the app doesn't work right away please allow the PyPI CDN a few minutes to fetch the file. 1: https://groups.google.com/d/msg/django-developers/vxCStIvpXc4/o68setV25e4J signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Proposal: Implement CORS & OAuth/OAuth2
I'm going to give a strong +1 here. In fact, can I inflate that to +100? As soon as something gets into Django itself then any improvements or API changes occur at a much slower pace. This is out of the necessity of providing a stable interface for developers. This becomes incredibly problematic when you need to have changes to reflect new developments in authentication and authorization. While things have currently 'stabilized' on OAuth 1 and OAuth 2, other systems may suddenly leap to the fore. In addition, major implementors of them (Twitter, Facebook, et al) are know to change things with little to no warning. Finally, there is always the risk of a security breach being discovered. Putting this into contrib means that the community cannot quickly adapt to the changes in the authentication landscape. If Django had a faster release pattern that might not be a problem, but I'm not so sure about it. As for the Django Packages site, we've been slowly working on fixing some bugs and bitrot. Once we've gotten the priority items done we plan to implement a way to promote and demote packages which will make grids much more useful. We've had this request several times for security-related packages, database connectors, and other things. We're not sure about the API yet, but there you go. -- 'Knowledge is Power' Daniel Greenfeld Principal at Cartwheel Web; co-author of Two Scoops of Django; Maintainer of Django Packages cartwheelweb.com | pydanny.com | django.2scoops.org On Sunday, July 28, 2013 5:25:43 PM UTC+2, Aymeric Augustin wrote: > > > I have to disagree. The ecosystem of third-party packages is much more > instrumental to the success of Django than contrib apps (with the exception > of the admin). Blessing a solution stifles competition, hinders progress, > and makes it much harder for (possibly better) alternatives to emerge. > That's why the current trend is to slim down contrib. > > -- > Aymeric. > > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
