Re: #3011 - Custom User Models -- Call for final review
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. Best regards ludwig -- 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/-/c_YYptksV1AJ. 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.
preventing 'csrftoken' cookie fixation attacks
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.
How to test patch
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/-/izYc2wsGgo0J. 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 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 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 7:33 AM, 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? > > Hi Jan, I've noticed your contributions on Trac this week. Thanks very much for taking the leap from user to contributor. Django wouldn't be where it was today without the efforts of people like yourself. So - how much testing is required? Enough to ensure that whatever it is you're submitting won't break when we apply the patch. Obviously, more is better, but you can apply a little discretion. If you're tweaking something in the template language, there's not much point running all the tests for the ORM. However, as a final check before you commit, it certainly wouldn't hurt to do one final run of the full test suite, just be sure. As for databases? Again, it depends a little bit on what you're testing. If you're modifying the template language, you can assume the ORM will do the right thing; just running the tests under SQLite will probably suffice. However, if your modifying the behaviour of queries, you need to run against every backend possible (that means SQLite, MySQL with MyISAM and InnoDB, PostgreSQL and Oracle). Don't worry *too* much about multiple versions of each database; there aren't *that* many inconsistencies between versions of databases, and if there is *that* will be the subject of the bug report (in which case, running the tests with different versions of the same database *will* be required). As for Python versions? At a minimum, you should be running the tests on a Python 2 version and a Python 3 version. It's generally a good idea to use the lowest supported version you can - so, Python 2.6 and 3.2 - because that's the most likely to reveal problems with accidentally using new features in the language. Ultimately, the goal is to make the best use of the development community's time. The core team are the bottleneck in the development process, because we're the only people who can commit code. That means that we need the community to make sure we waste as little of our time as possible. If we receive a patch that fails because it breaks the test suite, then that slows down the rate at which we can commit patches. So - the more testing you do to make sure that the core team doesn't get a broken patch, the better. Of course, we're not going to blame anyone if a test breaks in a weird or unexpected way. Mistakes happen -- we'd just rather they didn't :-) 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 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/-/8OZSXc4ujgoJ. 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.
