Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

(to complete my thought from the previous prematurely sent email) The bigger problem is that ANY rate-limiting framework is going to need heavy customization to work for all of the different ways Django is deployed. One size will definitely not fit all in this case. -- You received this message

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

Since you mention passwords specifically, I think this conversation is related to #16860. Throttling of passwords / adding captchas definitely falls under that ticket. https://code.djangoproject.com/ticket/16860 We probably should include a more general rate limiting framework (or at the very

Re: __getattr__ on SimpleTemplateResponse causes problems

On Thu, Sep 29, 2011 at 8:43 PM, Luke Plant wrote: > Hi all, > > r16568 [1] added SimpleTemplateResponse.__getattr__ as part of a fix for > #16326 [2]. > > There is one obvious bug in the implementation - it calls > super(...).__getattr__ which itself raises AttributeError

Re: r16912 and friends

On 29/09/11 23:39, Alex Gaynor wrote: > When I was writing it, I suspect my objective was to move the minimal > amount as possible to make the caching valid. I've got no problem with > having them be attributes, rather than closures. The patch looks fine > to me, feel free to commit. To keep

Re: __getattr__ on SimpleTemplateResponse causes problems

I wrote: > and in this case you would instead get > this message: > > "The rendered_content attribute was discarded when this >TemplateResponse class was pickled." > > which is completely false. ...which is completely false, so please ignore that part :-) The rest of the email was sound

__getattr__ on SimpleTemplateResponse causes problems

Hi all, r16568 [1] added SimpleTemplateResponse.__getattr__ as part of a fix for #16326 [2]. There is one obvious bug in the implementation - it calls super(...).__getattr__ which itself raises AttributeError because none of the base classes have __getattr__. It should use getattr instead. That

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

Thanks guys for the support. For reference, there is a previous thread "Brute force attacks", here: http://groups.google.com/group/django-developers/browse_thread/thread/71877ef02fb7c054/0b44e048b5bf4b77 Which does not mention captcha's btw. Luke, I'll think about it, but it will take some

Re: r16912 and friends

On Thu, Sep 29, 2011 at 6:36 PM, Luke Plant wrote: > On 29/09/11 18:23, Alex Gaynor wrote: > > > Your right, there should be an additional assert. FWIW it's not even a > > time/memory tradeoff, it's just savings. Type objects on every Python > > VM are some of the most

Re: r16912 and friends

On 29/09/11 18:23, Alex Gaynor wrote: > Your right, there should be an additional assert. FWIW it's not even a > time/memory tradeoff, it's just savings. Type objects on every Python > VM are some of the most expensive objects, and have various caches with > them, allowing those caches to stay

Re: prefetch_related - new feature suggestion

On Thu, Sep 29, 2011 at 4:40 PM, Florian Apolloner wrote: > > > On Tuesday, September 27, 2011 11:37:06 PM UTC+2, Peter wrote: >> >> I'd just like to chime in to say this should definitely be part of >> core - it's a common requirement, and whilst it could be a third party

Re: prefetch_related - new feature suggestion

On Tuesday, September 27, 2011 11:37:06 PM UTC+2, Peter wrote: > > I'd just like to chime in to say this should definitely be part of > core - it's a common requirement, and whilst it could be a third party > app, it certainly feels much more at home in core. > +1, especially if it works

Wrong JOIN with nested FKs

Hello, I'd like to draw your attention to ticket #16715: "Wrong JOIN with nested null-able foreign keys" https://code.djangoproject.com/ticket/16715 It seems that the Django query generator sometimes picks the wrong join type in the following situation: Model A | (Relation A/B:

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

you don't need to start from scratch as there's https://github.com/codekoala/django-axes -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit

Re: r16912 and friends

On Thu, Sep 29, 2011 at 1:20 PM, Luke Plant wrote: > On 29/09/11 17:13, Alex Gaynor wrote: > > Hi Luke (and the rest of the list ;)), > > > > Just saw r16912 and the subsequent commits, I wonder if you > > saw https://code.djangoproject.com/ticket/14270? I think most of

Re: r16912 and friends

On 29/09/11 17:13, Alex Gaynor wrote: > Hi Luke (and the rest of the list ;)), > > Just saw r16912 and the subsequent commits, I wonder if you > saw https://code.djangoproject.com/ticket/14270? I think most of the > changes in that patch and that you committed are the same, (which really > just

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

On 29/09/11 15:06, Wim Feijen wrote: > Would it be a good idea to write a ticket and patch to stop brute > force attacks, either by requiring people to fill in a captcha after > several failed login attempts; or by setting a time delay? If you search the archives of this list you'll find a fairly

r16912 and friends

Hi Luke (and the rest of the list ;)), Just saw r16912 and the subsequent commits, I wonder if you saw https://code.djangoproject.com/ticket/14270? I think most of the changes in that patch and that you committed are the same, (which really just paves the way for the caching I was going at).

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

+1 please On 9/29/11, Wim Feijen wrote: > Hello, > > Would it be a good idea to write a ticket and patch to stop brute > force attacks, either by requiring people to fill in a captcha after > several failed login attempts; or by setting a time delay? > > Mozilla Secure

prevent brute force attacks by acting on several failed logins, for example by using a captcha

Hello, Would it be a good idea to write a ticket and patch to stop brute force attacks, either by requiring people to fill in a captcha after several failed login attempts; or by setting a time delay? Mozilla Secure Coding Guidelines recommend in doing so, see:

Re: What's the different between regressiontests/signals_regress and modeltests/signals?

On Thu, Sep 29, 2011 at 3:04 PM, Silver_Ghost wrote: > `regressiontests/signals_regerss` was created in changeset 11710 and > `modeltests/signals` was created in changeset 6269.  It seems that they > perform same tests. The distinction between modeltests and

Re: URL-building with site-framework

Sorry, didn't search that way :) Thanks for the links On Sep 29, 12:51 pm, Marco Paolini wrote: > On 29/09/2011 12:12, momo2k wrote:> Hello, > > > this is my first post here and I hope this is the right place for > > discussing ideas django-features before reporting a

Re: URL-building with site-framework

On 29/09/2011 12:12, momo2k wrote: Hello, this is my first post here and I hope this is the right place for discussing ideas django-features before reporting a ticket. you don't need to open a ticket: #8995 covers this issue already I know that searching tickets is not the most thrilling

URL-building with site-framework

Hello, this is my first post here and I hope this is the right place for discussing ideas django-features before reporting a ticket. I encountered a problem related to the URL-building using sitemaps and the site-framework. I noticed there is no function for getting the "real" URL from the

Re: First time contribution, tests fails.

Ok, I got it working. Thanks. It was my fault. I guess I have been trying this without sourcing virtualenv. 2011/9/29 Sebastian Goll > On Thu, 29 Sep 2011 04:30:15 +0300 > Yaşar Arabacı wrote: > > > I have accepted

What's the different between regressiontests/signals_regress and modeltests/signals?

`regressiontests/signals_regerss` was created in changeset 11710and `modeltests/signals` was created in changeset 6269 . It seems that they perform same tests. And where should I place tests for