Re: type-field model inheritance
Since multi-table-inheritance is the only kind of inheritance (apart from abstract/proxy) supported by Django's ORM, I don't know what other type of inheritance django_polymorphic would be referring to... As per my original post, I want to store everything in one table (all subclasses have the same fields). I just want to have different python behaviour for subclasses. Basically proxy models but with a known type and polymorphic querysets. I still haven't looked into django_polymorphic to see if it does that, but it seems like it could easily... Hopefully I'll get time to play with it in the next couple days. Regards Craig -- 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: type-field model inheritance
Hi Carl, > FWIW, django-model-utils [1] includes an InheritanceManager that > implements polymorphic queries in a single query via select_related. Ah, there goes my theory that I thought of it first :) And of course introspection of subclasses via the reverse OneToOne descriptors is perfect. -- 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: the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off
On Fri, Mar 4, 2011 at 10:24 AM, Viktor Kojouharov wrote: > > I'm testing my software with the new rc1 release of django 1.3, and I came > onto a particularly nasty problem. > I have a model which uses a Postgresql 'point' type, for which I've defined > a field as: > http://dpaste.com/472467/ > > I also have another model, which references this one with a foreign key. > When saving an instance from this other model, django throws the following > exception: > http://dpaste.com/472475/ > The exception is due to the new 'DISTINCT' part of the SELECT query. > Because of the point field, there is no way to select 'unique' entries, > because Postresql cannot compare points. > So the question is, is there any way to turn off this distinct query, and > just force django to assume that all entries are unique? > Looks like the change that added distinct to this query is this one: http://code.djangoproject.com/changeset/15607 It's probably best if you open a ticket in trac ( http://code.djangoproject.com/newticket) for this. I can't think offhand how to solve both the problem that changeset fixed and the one you are encountering Karen -- 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: type-field model inheritance
Hi Simon, On Mar 4, 3:27 am, Simon Meers wrote: > +1 for better polymorphic support in Django core; it is a very common > problem which could do with an efficient and elegant solution. > Regarding efficiency, if you can keep track of your subclasses > effectively (potentially using a registry if not introspection), you > can use select_related to retrieve heterogeneous multi-table > inheritance models in a single query (see example in [1]). I haven't > looked deeply enough into django_polymorphic to see if it includes > such optimisations. I'm sure we could further tweak the internals to > make things more efficient and developer-friendly in this regard. FWIW, django-model-utils [1] includes an InheritanceManager that implements polymorphic queries in a single query via select_related. [1] https://github.com/carljm/django-model-utils -- 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: type-field model inheritance
Hi Craig, On Mar 4, 1:03 am, Craig de Stigter wrote: > It looks like django_polymorphic does what I want. I'm not yet sure why it > says it takes one query per type of model in a queryset. Unless it is > talking about multi-table inheritance, in which each type would require a > different join. But I'll look in more detail in the next few days and no > doubt it will become clear. Since multi-table-inheritance is the only kind of inheritance (apart from abstract/proxy) supported by Django's ORM, I don't know what other type of inheritance django_polymorphic would be referring to... Carl -- 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: Problem due to contenttype cache
On Mar 4, 5:55 am, Rahul wrote: > When i ran test cases of multiple_databases model of regressiontests > then "test_generic_key_deletion" test case gave Error at the point > where it was trying to create Review object using "other" db, > but when i ran "test_generic_key_deletion" test case only then it > passed perfectly. > > When i narrowed the problem and run this test case with > "test_generic_key_cross_database_protection" then even it gives Error > at same line. > > In my investigation i found that in > "test_generic_key_cross_database_protection" test case, one Reiview > object is getting created and because there exist FK relationship with > ContentType, content type record for this is getting populated in DB > and content type lookup are cached. At the end of this test case, > content type record gets cleared by rollback, but content type lookup > still remain in cache, so that when inside "test_generic_key_deletion" > it tries to create Review object it gets content type from the cache > and does not have to go to DB. Next when it tries to populate review > table, Integrity error is raised as it has not made entry to content > type table. > > I also tested it with InnoDB and getting same error here as well. > > Could you please let me know if you wants to let it gives error for > this test case for InnoDB or I am running this wrong way. Any failed test on a supported backend (which includes InnoDB) is a bug. Please file a ticket, including this information and the full settings with which you're running the tests. Thanks! Carl -- 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: Brute force attacks
On 03/04/2011 11:56 PM, Rohit Sethi wrote: Hi all, I wanted to revisit a key security discussion. Brute force attacks are the 7th most prevalent attack by number of incidents in the Web Hacking Incidents Database (http://projects.webappsec.org/w/ page/13246995/Web-Hacking-Incident-Database), which tracks publicly disclosed breaches in web application. This is ultimately because many applications do not have provisions to prevent brute-forcing. Django’s out of the box admin-site authentication is very awesome – so awesome, in fact, that inevitably people have and will continue to use it for more than just administrative users. Clearly Django takes authentication seriously. Can we revisit the idea of protecting against brute force authentication out of the box? (http:// groups.google.com/group/django-developers/browse_thread/thread/ 7559145e8c85d8c/b96c9a81e97f333b?lnk=gst&q=account +lockout#b96c9a81e97f333b). In particular, the idea of using throttling such as http://github.com/simonw/ratelimitcache/ or http://code.google.com/p/django-brutebuster/. Would you be willing to discuss further? My development team is willing to contribute whatever is needed to get this done if you think it's fruitful I'm the author of BruteBuster, and I (obviously) think that an easy-to-use bruteforce protection is needed in Django. This being said, I'd suggest to let the code evolve from real-life usage scenarios before being considered for inclusion in the core or in contrib. So, take your pick (or write your own lib), see what works and what doesn't, ask for/implement improvements, then evaluate again. Once there is a clear, proven winner (something like South ;), then ask for inclusion in Django. In the particular case of BruteBuster, feel free to contact me directly with any problems/suggestions (the development of BruteBuster has been largely neglected, due to the code working OK for our needs and lack of interest from other parties). On 03/05/2011 12:22 AM, Shawn Milochik wrote: I have an immediate interest in this discussion. One of my company's Django apps was recently subjected to an external risk assessment team audit. They found the fact that three invalid password attempts didn't lock out the user to be completely unacceptable. ... Also, the thread referred to above discusses throttling, whereas the "recommendation" provided to us by the auditors was user lockout requiring administrator activity (human intervention) to unlock. I find myself doing similar audits often, and from your description it looks like the auditors are simply going over a checklist with prescriptions, without much consideration of what's reasonable. Such kind of restrictive locking is ridiculous for most use-cases. Unless you are a very large corporation/government agency/extremely high security facility, requiring manual intervention from the administrator after 3 failed attempts would simply annoy users and prevent them from doing their work effectively. If there is any enforced password strength, bruteforcing would need *lots* of attempts to succeed. If you hadn't had your coffee in the morning, on the other hand, it is quite easy to trip over the 3 failed attempts limit. What happens if the sysadmin is not available to unlock your account? On a side note, throttling vs locking - you can implement effective locking with throttling (say, throttle rate of 3 attempts in 10**6 minutes), but the opposite is not true. I think it is clear which is the more flexible approach. -- Best Regards, Emil Filipov Cyber Security Consulting Ltd. http://csc.bg -- 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: Brute force attacks
On Fri, 2011-03-04 at 17:22 -0500, Shawn Milochik wrote: > the thread referred to above discusses throttling, whereas the > "recommendation" provided to us by the auditors was user lockout > requiring administrator activity (human intervention) to unlock. This *creates* a denial of service vulnerability, especially if your usernames are public. (Otherwise the attacker has to guess at them.) Richard signature.asc Description: This is a digitally signed message part
Re: Brute force attacks
do you guys know about django-axes? (http://code.google.com/p/django-axes/) it allows you to lock out IP or IP/User Agent combo on a given number of failures. On Fri, Mar 4, 2011 at 5:22 PM, Shawn Milochik wrote: > I have an immediate interest in this discussion. One of my company's > Django apps was recently subjected to an external risk assessment team > audit. They found the fact that three invalid password attempts didn't > lock out the user to be completely unacceptable. > > Granted, this is something that I should have applied myself, and if > it were automatically part of Django it would frustrate many > developers because it would inconvenience their users. > > However, considering it's an OWASP concern, and likely a wheel which > will be reinvented repeatedly, I would like to see it in Django. I am > willing to put my time into the effort. If Rohit and his team end up > taking on the project I will coordinate with them to see how I can > help. > > It seems that any implementation of this would require another value > for settings.py, and I know that's something not done lightly. Also, > the thread referred to above discusses throttling, whereas the > "recommendation" provided to us by the auditors was user lockout > requiring administrator activity (human intervention) to unlock. > > So the next question is whether the core dev team is interested in > discussing configurable lockout (number of attempts and human > intervention or timeout to release the lock), throttling, or both. > Then, how to best go about it. > > Incidentally, I'll be at PyCon if anyone wants to get together after > hours to work on this during the main days (I won't be at the > sprints). > > Shawn > > -- > 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. > > -- Brendan Smith, IT Specialist National Priorities Project http://www.nationalpriorities.org http://www.costofwar.com http://www.facebook.com/nationalpriorities 413 584 9556 -- 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: Brute force attacks
I have an immediate interest in this discussion. One of my company's Django apps was recently subjected to an external risk assessment team audit. They found the fact that three invalid password attempts didn't lock out the user to be completely unacceptable. Granted, this is something that I should have applied myself, and if it were automatically part of Django it would frustrate many developers because it would inconvenience their users. However, considering it's an OWASP concern, and likely a wheel which will be reinvented repeatedly, I would like to see it in Django. I am willing to put my time into the effort. If Rohit and his team end up taking on the project I will coordinate with them to see how I can help. It seems that any implementation of this would require another value for settings.py, and I know that's something not done lightly. Also, the thread referred to above discusses throttling, whereas the "recommendation" provided to us by the auditors was user lockout requiring administrator activity (human intervention) to unlock. So the next question is whether the core dev team is interested in discussing configurable lockout (number of attempts and human intervention or timeout to release the lock), throttling, or both. Then, how to best go about it. Incidentally, I'll be at PyCon if anyone wants to get together after hours to work on this during the main days (I won't be at the sprints). Shawn -- 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.
Brute force attacks
Hi all, I wanted to revisit a key security discussion. Brute force attacks are the 7th most prevalent attack by number of incidents in the Web Hacking Incidents Database (http://projects.webappsec.org/w/ page/13246995/Web-Hacking-Incident-Database), which tracks publicly disclosed breaches in web application. This is ultimately because many applications do not have provisions to prevent brute-forcing. Django’s out of the box admin-site authentication is very awesome – so awesome, in fact, that inevitably people have and will continue to use it for more than just administrative users. Clearly Django takes authentication seriously. Can we revisit the idea of protecting against brute force authentication out of the box? (http:// groups.google.com/group/django-developers/browse_thread/thread/ 7559145e8c85d8c/b96c9a81e97f333b?lnk=gst&q=account +lockout#b96c9a81e97f333b). In particular, the idea of using throttling such as http://github.com/simonw/ratelimitcache/ or http://code.google.com/p/django-brutebuster/. Would you be willing to discuss further? My development team is willing to contribute whatever is needed to get this done if you think it's fruitful -- 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: Storing language in session/cookie
2011/3/4 Mikołaj S. : > I know, but it just seems so obvious to me that I can't believe no one have > ever encountered this problem before - I felt like I should ask ;) > > -- > 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. > Here are some tickets you might find interesting: http://code.djangoproject.com/ticket/13217 http://code.djangoproject.com/ticket/12794 http://code.djangoproject.com/ticket/65 If you disable sessions, django will use a cookie to store the language. If you have sessions enabled, then django checks the session first which results in adding "Vary: Cookie" (even if it doesn't contain any info). I'm not an expert on caching, but even if you add a seperate cookie for a language, but keep the sessions framework enabled, wouldn't that still break caching ? After all the (session, language) cookie pair is still unique and the "Vary" header doesn't let you name specific cookies, AFAIK. -- Łukasz Rekucki -- 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: Storing language in session/cookie
I know, but it just seems so obvious to me that I can't believe no one have ever encountered this problem before - I felt like I should ask ;) -- 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: Storing language in session/cookie
I'm not familiar with that subsystem, but if what you say is correct, you should open a ticket. That sounds like a definite issue to me. -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.
the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off
Hello, I'm testing my software with the new rc1 release of django 1.3, and I came onto a particularly nasty problem. I have a model which uses a Postgresql 'point' type, for which I've defined a field as: http://dpaste.com/472467/ I also have another model, which references this one with a foreign key. When saving an instance from this other model, django throws the following exception: http://dpaste.com/472475/ The exception is due to the new 'DISTINCT' part of the SELECT query. Because of the point field, there is no way to select 'unique' entries, because Postresql cannot compare points. So the question is, is there any way to turn off this distinct query, and just force django to assume that all entries are unique? -- 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.
Storing language in session/cookie
Hi, I'd like to make a proposal of changing the way that current language is stored, at least, making this changeable by settings. The problem is that even for non-logged users their language is stored in session (if it's supported or in the cookie otherwise). That creates a session for every client, which makes serving static (ofc I mean static, but not media) content through an upstream cache (such as Squid) really inefficient. I suppose selected language is not that secret to protect it by storing in session, and cookie is just ok. For cookie-varying cache it's a huge difference. I may be very wrong - in that case please just tell me what design concept lays behind this system. ;) -- 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.
Problem due to contenttype cache
When i ran test cases of multiple_databases model of regressiontests then "test_generic_key_deletion" test case gave Error at the point where it was trying to create Review object using "other" db, but when i ran "test_generic_key_deletion" test case only then it passed perfectly. When i narrowed the problem and run this test case with "test_generic_key_cross_database_protection" then even it gives Error at same line. In my investigation i found that in "test_generic_key_cross_database_protection" test case, one Reiview object is getting created and because there exist FK relationship with ContentType, content type record for this is getting populated in DB and content type lookup are cached. At the end of this test case, content type record gets cleared by rollback, but content type lookup still remain in cache, so that when inside "test_generic_key_deletion" it tries to create Review object it gets content type from the cache and does not have to go to DB. Next when it tries to populate review table, Integrity error is raised as it has not made entry to content type table. I also tested it with InnoDB and getting same error here as well. Could you please let me know if you wants to let it gives error for this test case for InnoDB or I am running this wrong way. Thanks, Rahul Priyadarshi -- 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: type-field model inheritance
On 4 March 2011 17:03, Craig de Stigter wrote: > Hi guys > > Thanks for pointing those out. I knew I couldn't have been the first to want > this. I guess I just didn't know the right words to search for here. > It looks like django_polymorphic does what I want. I'm not yet sure why it > says it takes one query per type of model in a queryset. Unless it is > talking about multi-table inheritance, in which each type would require a > different join. But I'll look in more detail in the next few days and no > doubt it will become clear. +1 for better polymorphic support in Django core; it is a very common problem which could do with an efficient and elegant solution. Regarding efficiency, if you can keep track of your subclasses effectively (potentially using a registry if not introspection), you can use select_related to retrieve heterogeneous multi-table inheritance models in a single query (see example in [1]). I haven't looked deeply enough into django_polymorphic to see if it includes such optimisations. I'm sure we could further tweak the internals to make things more efficient and developer-friendly in this regard. Cheers, Simon [1] http://stackoverflow.com/q/5175009/284164 -- 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.
