Hi all,
This is a second and final call for feedback on the multidb branch.
Barring any objections or the discovery of major problems, my
intention is to commit this early next week, hitting the alpha 1
feature deadline by the skin of our collective teeth :-)
There has been one big change since
On Thu, Dec 17, 2009 at 6:47 PM, Luke Plant wrote:
...
> The problem with signals is that they don't return values, and so the
> mechanism can't interact with the actual login process. It can only
> notice that something is going on and try to stop it by some external
> mechanism.
Actually, they
Hey guys,
How slow can brute force attacks be? That is, why not just let the web
server/load balancer/network stack rate limit client connections to
prevent DoS, and effectively thwart brute force attacks?
(I have no idea how good password guessing has been these days, so
this isn't the most well
Hi Tom,
> Hello Everyone,
>
> I noticed that Django's contrib.auth doesn't provide a mechanism
> for detecting a password brute force attack. This is necessary for
> a couple projects I'm working so I have to implement some kind of
> solution and would really like to do it in such a way that i
And here is another stab at it:
http://code.google.com/p/django-brutebuster/
On Dec 17, 9:30 pm, Tom wrote:
> Hello Everyone,
>
> I noticed that Django's contrib.auth doesn't provide a mechanism for
> detecting a password brute force attack. This is necessary for a
> couple projects I'm working s
On Thu, Dec 17, 2009 at 2:30 PM, Tom wrote:
> Hello Everyone,
>
> I noticed that Django's contrib.auth doesn't provide a mechanism for
> detecting a password brute force attack. This is necessary for a
> couple projects I'm working so I have to implement some kind of
> solution and would really li
Hello Everyone,
I noticed that Django's contrib.auth doesn't provide a mechanism for
detecting a password brute force attack. This is necessary for a
couple projects I'm working so I have to implement some kind of
solution and would really like to do it in such a way that it could
get contributed
Mike Malone wrote:
> In my opinion, using the Site module and settings files is damn
> annoying.
My point is that we better fix these annoyances than leave this way of
doing things altogether.
> I never use the Site module
This is by itself is not the reason why it might be annoying. Django
ac
Michael Richardson wrote:
> With these cases (the former more so than the latter) you are creating
> URLs for an entirely separate project, not your own, essentially.
Not "entirely separate". These are projects sharing much of the
codebase, just having different SITE_ID in settings.
Anyway there
I've made a few more changes, added many more tests and written
documentation. This now fixes #6188, #6304, #6618, #6969, #8758,
#8989, #10334, #11069 and #11973.
Any final feedback would be appreciated. I'll put it together as a
patch and put it in a ticket as soon as possible.
Thanks,
Be
10 matches
Mail list logo
