Re: How to test patch
Another long time user here (at some point I'd love to make the jump to contributor, just need to find more time) - out of interest, is there a reason we don't use Travis? I wonder if that might help those with commit access, since pre-tested pull requests would mean you could have confidence that the tests at least pass. Apologies if this has been discussed before (there are a few contributors to this group called Travis, which made searching a bit tricky!). Dom On Sunday, October 28, 2012 2:11:56 AM UTC, ptone wrote: > > Thanks Jan for the contributions. > > I'll add a couple bits to Russ's excellent reply. > > I generally will run just a specific test, or a subset of the tests while > developing the patch initially, this is much faster and can let you iterate > much more quickly. > > Julien has put together a great tool for running the full test suite - > allowing you to test more python versions including the GIS stuff: > > https://github.com/jphalip/djangocore-box > > Finally - note that for some work, you will occasionally hit test > interaction issues, where global state causes unintended failures to happen > in apparently unrelated tests. Hopefully this won't happen, but if it does > and you're stumped, reach out for help. > > -Preston > > On Saturday, October 27, 2012 4:33:35 PM UTC-7, Jan Bednařík wrote: >> >> Hi all, >> >> I'm using Django for more than four years and last week I started >> contributing. >> >> In docs about contributing I didn't find how detailed should be my >> testing while I'm writing or reviewing patch? Is enough to run tests only >> for patched module? Or should I run full test suite for each patch? Which >> combinations of Python versions and database engines are mandatory? >> >> So far I was running Python 2.7 & SQLite3 for development/review testing >> of module. Python 3.2 & SQLite3, Python 2.7 & PostgreSQL for patched module >> and in the end Python 2.7 & SQLite3 full test suite (with selenium, etc.). >> Is this workflow ok? >> >> Jan Bednařík aka Architekt >> > -- 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/-/ZZkz9Q6B9BAJ. 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: How to test patch
Hi Jan. How I doing it. Until I work with patch I run only part of tests.(If I make test at "modeltests/serializers/tests.py " I run only "./runtests.py --settings=test_sqlite serializers" for fast checking). And before to submit patch on Trac I always run all tests. That allows to working faster than if run always all tests. -- 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/-/TR_n2JsNmfIJ. 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: How to test patch
On Sun, Oct 28, 2012 at 3:55 PM, Dominic Rodger wrote: > Another long time user here (at some point I'd love to make the jump to > contributor, just need to find more time) - out of interest, is there a > reason we don't use Travis? I wonder if that might help those with commit > access, since pre-tested pull requests would mean you could have confidence > that the tests at least pass. Apologies if this has been discussed before > (there are a few contributors to this group called Travis, which made > searching a bit tricky!). > > We do have a CI server (a Jenkins install) - you can find it here: http://ci.django-cms.org/job/Django/ We don't currently test every fork or pull request on GitHub, but that's certainly an interesting idea, especially if we could get validation that a pull request passes the full test suite. I haven't spent any time messing around with Travis configuration to know how hard this would be to set up -- and whether the build failures can be communicated in an effective way. If you're looking for a way to contribute, investigating the options here might be an interesting place to start. Yours, Russ Magee %-) -- 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: How to test patch
Thanks for your feedbacks, they are really helpful. I noticed existence of Jenkins test runner and also I found old discussion about Django's testing infrastructure: https://groups.google.com/d/topic/django-developers/_HfxwT7sVu0/discussion What is the actual status of automated testing infrastructure? Is it just one Jenkins server which is continuously running tests on master branch? Jan On Sun, Oct 28, 2012 at 10:20 AM, Russell Keith-Magee wrote: > > On Sun, Oct 28, 2012 at 3:55 PM, Dominic Rodger > wrote: >> >> Another long time user here (at some point I'd love to make the jump to >> contributor, just need to find more time) - out of interest, is there a >> reason we don't use Travis? I wonder if that might help those with commit >> access, since pre-tested pull requests would mean you could have confidence >> that the tests at least pass. Apologies if this has been discussed before >> (there are a few contributors to this group called Travis, which made >> searching a bit tricky!). >> > > We do have a CI server (a Jenkins install) - you can find it here: > > http://ci.django-cms.org/job/Django/ > > We don't currently test every fork or pull request on GitHub, but that's > certainly an interesting idea, especially if we could get validation that a > pull request passes the full test suite. > > I haven't spent any time messing around with Travis configuration to know > how hard this would be to set up -- and whether the build failures can be > communicated in an effective way. If you're looking for a way to contribute, > investigating the options here might be an interesting place to start. > > Yours, > Russ Magee %-) > > -- > 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. -- 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: #3011 - Custom User Models -- Call for final review
Yeah i got your point and thats totally fine - i'll definitely find a workaround ;-) Just found a way to describe my point of view in a little different way: * Why is there a need to have Authentication and Authorization in one App - when both answer a totally different purpose? * But the answer - as you said - it might be the more convenient way in 90% of the use cases... And because of that - easier to use. => right..? Just want to make sure thinking abt it this way brings you to the same answer.. I'm a little biased, because for me the union of both is unfavorable. So thanks you took the time to think abt it. Nice job anyway! best regards ludwig Am Sonntag, 28. Oktober 2012 02:05:47 UTC+2 schrieb Russell Keith-Magee: > > > On Sat, Oct 27, 2012 at 7:25 PM, Ludwig Kraatz > > > wrote: > >> Hi Russ, >> >> >>> >>> > - The last_login field is in the AbstractBaseUser, but it isn't >>> > documented as a required field. Is this field required for something? >>> > Is it needed as part of AbstractBaseUser? >>> >>> Yes, last_login is required - it's needed in order to generate >>> password reset tokens etc. >>> >>> It isn't documented because we *really* want people to be subclassing >>> AbstractBaseUser, not building their own User from scratch. >>> >> >> >> I totally understand u want people to subclass the AbstractBaseClass. But >> what if some Django based system just doesn't need any passwords at all? If >> All authentification might be handled by LDAP, SSO or whatever.. >> It might be *ok* then to have a password field for every user just set to >> *unusable* (but not nice at all..). But then having the user table always >> being updated on logins is just not necessary. If one (me) maybe even wants >> to store recent actions - as logins - in a completely different app / table >> / db - than the user table would definitely benefit from not being accessed >> without any need on every login. >> >> So I really don't think its the best way to force any subclassed model to >> use the last_login (and password) field. Why not having an >> AbstractPasswordUser and an >> * AbstractNaked-I-Dont-Have-Anything-except-a-username-User? >> >> I really appreciate you're offering the possibility of having Custom >> Users this easy now, but please think again about the password and >> especially the last_login field. >> >> Thanks for your feedback. However, I'm going to say no in this case, for > two reasons. > > Firstly, a framework like Django can't ever hope to suppose *every* > possible use case. That's one of the side effects of being a framework; in > order to make the framework easily usable in 90% of cases, and possible to > use in 95% of cases, you have to throw 5% of cases overboard. That's > unfortunate, but it's also the price you pay for having something easy to > use for 90% of use cases. > > Secondly, because this is Python, there's actually nothing preventing you > from doing exactly what you describe in your own code. Although Django > provides an AbstractBaseUser, there are any explicit type checks for that > specific class. We rely on duck typing when the implemented class is > actually used. The base class is just an implementation assistant, > providing the common pieces that most users will need (and, in the case of > password, we explicitly *don't* want them implementing themselves). > > So - that means that if you want to write a User object that has no > password field, you can do that; the only catch is that you'll need to make > sure you don't ever hit a line of code that expects the existence of a > password field. That means none of the login forms will work, none of the > user creation forms (or createsuperuser) will work, and you'll need to > write your own authentication backend. However, the important part of the > swappable User mechanic -- the ability to make ForeignKey/M2M relations > with *your* User model -- won't be encumbered at all. As far as I'm aware, > with the exception of createsuperuser, all these password-dependent places > should be user-configurable; so, for example, you can specify your own > login form and template for the login view. > > If I'm mistaken on any of this, I'm certainly open to patches that to > remove or weaken the dependency on a specific password field. However, I > don't think we need to ship a super-minimal User base class, if for no > other reason that we *really* want to discourage people from writing their > own implementation of a password field. > > Yours, > Russ Magee %-) > > -- 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/-/3DKNLBzKuVwJ. 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
Re: How to test patch
Travis or Jenkins can be setup to test PR's and use Github's API to mark the PR as good to merge or not. On Sunday, October 28, 2012 at 5:20 AM, Russell Keith-Magee wrote: > > On Sun, Oct 28, 2012 at 3:55 PM, Dominic Rodger (mailto:dominicrod...@gmail.com)> wrote: > > Another long time user here (at some point I'd love to make the jump to > > contributor, just need to find more time) - out of interest, is there a > > reason we don't use Travis? I wonder if that might help those with commit > > access, since pre-tested pull requests would mean you could have confidence > > that the tests at least pass. Apologies if this has been discussed before > > (there are a few contributors to this group called Travis, which made > > searching a bit tricky!). > > > > We do have a CI server (a Jenkins install) - you can find it here: > > http://ci.django-cms.org/job/Django/ > > We don't currently test every fork or pull request on GitHub, but that's > certainly an interesting idea, especially if we could get validation that a > pull request passes the full test suite. > > I haven't spent any time messing around with Travis configuration to know how > hard this would be to set up -- and whether the build failures can be > communicated in an effective way. If you're looking for a way to contribute, > investigating the options here might be an interesting place to start. > > Yours, > Russ Magee %-) > > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- 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: preventing 'csrftoken' cookie fixation attacks
Hi Mike, If an attacker can set cookies on your domain, you've got much larger problems than whether or not they know the nonce. Even if you do change the nonce on login, you are still vulnerable to multiple forms of session fixation attacks. To quote myself from an earlier mail to this list: https://groups.google.com/forum/#!msg/django-developers/3vG7H3kRBZ0/rZmJFazA4YMJ Django's CSRF implementation differs from many others which store CSRF information alongside session information on the server. The CSRF mechanism functions by matching a token provided in a form with a token provided as a cookie in the browser. If you set the cookie to 'zzz', it will still function perfectly well. The security comes from the fact that an attacker cannot set the cookie, not that it happens to contain any specific cryptographic value. Given this property, if an attacker can set a CSRF token cookie, rotating it during login makes no functional difference to your application security. The solution here is to configure your application so that an attacker cannot read or set any cookies. The best way to do this is to enable HSTS including subdomains, get yourself added to the browser pinning lists, make sure your domain contains no XSS bugs, and encourage users with browsers that do not support HSTS to switch to browsers that do. If the specific properties of Django's CSRF implementation do not work for your application, you may be interested in this alternate CSRF middleware implementation: https://github.com/mozilla/django-session-csrf As always, when reporting potential security problems, please use the secur...@djangoproject.com address. Regards, -Paul On Sat, Oct 27, 2012 at 7:01 PM, wrote: > Hi there, > > I'd like to discuss the behavior of the 'csrftoken' cookie that is used > for django's CSRF protection [1]. > I noticed that the cookie content does not change when performing a login > (like the 'sessionid' cookie does). > According to [1] this seems to be the documented behavior: "This cookie is > set by CsrfViewMiddleware. It is meant to be *permanent*" > but the csrftoken content should change on login (like the sessionid > cookie does). > If the attacker is able to set the cookie (this can happen before the > victim performs the login) he will know the > nonce that is needed to bypass the CSRF protection: > "The malicious user would have to know the nonce, which is user specific > (using a cookie)." [2] > > Do you agree that the 'csrftoken' cookie should be treated like the > session cookie when it comes to fixation attack prevention (cookie should > change on login)? > Can this be fixed directly in the CsrfViewMiddleware or can/should > developers address this in the webapplication? > > kind regards, > Mike > > -- > 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. > -- 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: #3011 - Custom User Models -- Call for final review
On Sun, Oct 28, 2012 at 8:54 AM, Ludwig Kraatz wrote: > Just found a way to describe my point of view in a little different way: > * Why is there a need to have Authentication and Authorization in one App - > when both answer a totally different purpose? * > But the answer - as you said - it might be the more convenient way in 90% of > the use cases... And because of that - easier to use. > => right..? You nailed it. In systems which separate the two, it's extremely common for developers to mistake one for the other, and build insecure systems. By providing both together by default, developers who have never considered the fact that the two concepts can be separate will do the right thing, and the 90% case for the rest of us of "I need both together" is also met. -Paul -- 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.
Github tags
Hi, Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5 alpha tagged on the github repository? The tagging seems to have fallen behind with these releases. Thanks, -- Matt -- 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.
Complicated, strange bug in ``prefetch_related`` when used in the context of a test client
I'm still working on forming some sort of understanding of what exactly
causes this and/or what is even going on, so any help is much appreciated.
The resultant attached "bars" in the following example:
queryset = Foo.objects.all()
queryset = queryset.prefetch_related('bars__baz')
obj = queryset.get(pk=1)
are different from the results of:
obj = Foo.objects.all().prefetch_related('bars__baz').get(pk=1)
And, the results attached in the second example are inconsistent as well.
In order to reproduce this, you need to first query for the "Foo", then add
some "bars" to the DB, then perform the above examples.
This only seems to occur, at least measurably, during tests when using
``self.client.get(...``, where the view that is being requested performs
the queries.
I'm using ``TransactionTestCase``, sqlite3, and Django latest master,
pulled about an hour ago, and I've also tried the new live server test case
with the same results.
Note: If I modify django.db.models.query # 590 to the following, the bug
doesn't occur (not to suggest that the following is a solution, but it
might help to debug):
prefetch_related_objects([], self._prefetch_related_lookups)
--
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/-/qpkxQFmjlvoJ.
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.
