Hi all,
For your consideration, I present a patch to resolve #12815 and
#12816, adding a TemplateResponse and a render() shortcut.
Barring objection or feedback, my intention is to commit this patch mid week.
This patch adds two features.
Firstly, it adds a render() shortcut. This is just
rende
On Sun, Nov 28, 2010 at 12:19 AM, Christophe Pettus wrote:
> Let's do the math. The space of eight alphanumeric character passwords is
> 2.8e12. Even assuming you can cut two orders of magnitude off of that with
> good assumptions about the kind of passwords that people are picking, this
> me
I wrote:
> A dictionary attack works by consulting a precomputed set of passwords and
> their hashes, (pwd, hash(pwd)). The attacker then runs down the dictionary,
> comparing hashes; if they get a hit, they know the password. The salt
> defeats this by making the pwd -> hash(pwd) mapping inco
On Nov 27, 2010, at 9:01 PM, Tom X. Tobin wrote:
> But how far are you willing to go in your assumption of the worst-case
> computational ability of your attacker? Would tuning the hash to
> (say) a 10ms delay for your web server's modest hardware translate
> into a significant delay for an attac
On Sat, Nov 27, 2010 at 11:47 PM, Christophe Pettus wrote:
> Actually, no, the situations are really quite asymmetrical. In order to
> brute-force a password, an attacker has to be able to try many, many
> thousands of combinations per second. To log in a user, an application has
> to do it e
On Sun, Nov 28, 2010 at 9:17 AM, Jamie Rumbelow wrote:
> Hello All,
> Kevin's got a point, and actually, why aren't Django's components abstracted
> as a generic rule? Things like django.contrib.session and
> django.contrib.comments could be easily abstracted to allow for pluggable
> drivers into
On Nov 27, 2010, at 8:05 PM, Tom X. Tobin wrote:
> Your application ends up just
> as hobbled by such an algorithm as a potential attacker.
Actually, no, the situations are really quite asymmetrical. In order to
brute-force a password, an attacker has to be able to try many, many thousands
of
On Sat, Nov 27, 2010 at 10:14 PM, Christophe Pettus wrote:
> Right now, Django's auth system pretty much uses sha1 hardwired in
> (literally, in the case of User.set_password) for the hash. For a discussion
> of why a general-purpose hash function is not the best idea in the world for
> passwo
Hello All,
Kevin's got a point, and actually, why aren't Django's components abstracted
as a generic rule? Things like django.contrib.session and
django.contrib.comments could be easily abstracted to allow for pluggable
drivers into other backends quite easily. It'd be easy to make
backward-compat
Hi, all,
Right now, Django's auth system pretty much uses sha1 hardwired in (literally,
in the case of User.set_password) for the hash. For a discussion of why a
general-purpose hash function is not the best idea in the world for password
encryption, see:
http://codahale.com/how-to-sa
Hi,
I'd like to make a suggestion about the build in comments framework.
Right now, even though you can write your own extension to the
comments framework, it is always tied to database models. I am trying
to build an extension that uses the API offered by Disqus, meaning I
don't want to use the l
On Sun, Nov 28, 2010 at 3:12 AM, dkeeney wrote:
>
> I am working on adding support for another database to Django's ORM.
>
> Is there a certain set of tests in the Django package that test the
> ORM separately from other tests? Can anyone recommend a list of tests
> that I should ensure passing?
I am working on adding support for another database to Django's ORM.
Is there a certain set of tests in the Django package that test the
ORM separately from other tests? Can anyone recommend a list of tests
that I should ensure passing?
Offhand, I would expect *all* tests run from 'manage.py t
Hi there -
wondering why ImageField doesn't rely on width_field and height_field
(if present and populated) for the dimensions? (i.e. from ImageField's
perspective these seem to be "write-only" fields).
This seems pretty unperformant (moving to ridiculously unperformant if
you're using a remote s
On Sat, 2010-11-27 at 09:36 +0800, Russell Keith-Magee wrote:
> So - if you can rephrase this in terms of a function/class API where
> someone can define a mechanism for enforcing password strength, and
> provide two implementations (the "any password is OK" policy and the
> "cracklib policy" woul
Sorry, I've fallen asleep yesterday.
I "updated" Django to r14714 and it works fine. There are two
changesets after this one which are related to ORM, so I think the
problem is with them.
--
Valya Golev
On Sat, Nov 27, 2010 at 7:07 AM, Alex Gaynor wrote:
> On Fri, Nov 26, 2010 at 8:26 PM, Ru
16 matches
Mail list logo
