On Sat, Jun 28, 2008 at 5:32 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
[...]
> 1) The confusion between 0/1 and False/True on BooleanField
>
> This is an issue with MySQL support that has existed for some time.
> Strictly, it's only an issue with the test suite because 0 is not
>
I just spent a while chasing my tail because I was passing the results
of get_list_or_404 to the QuerySetPaginator, not realizing that it
returns a list and not a QuerySet object.
When I tried to get the count, it raised the exception: "TypeError:
count() takes exactly one argument (0 given)"
I
On Jun 28, 11:21 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> MD5 is 8 chars shorter. Do we really need SHA-1? If I understand
> correctly, the only known vulnerability with MD5 is the ability to
> force collisions, but that will not help an attacker in this case.
> The only thing that an
I've created the new patch for this issue.
As I said before, IMHO it'll be important to commit this patch before
1.0, so current behavior is very uncomfortable for users in many
countries. And finally the patch was quite simple, just a couple of
javascript lines of code (I didn't know before
On Saturday 28 June 2008 21:48:24 Simon Willison wrote:
> A further micro-optimisation is to leave out the hyphen entirely,
> since an SHA-1 hash is always 40 characters long (we should
> probably use that instead of MD5).
MD5 is 8 chars shorter. Do we really need SHA-1? If I understand
On Jun 28, 10:01 pm, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> If you add the timestamp into both the hash and the token then you can
> achieve a more granular expiration policy.
That's the approach I use for djangopeople.net - the problem is that
including the timestamp lengthens the URL yet
If you add the timestamp into both the hash and the token then you can
achieve a more granular expiration policy.
E.g., let's say the timestamp is something like '200806282255', indicating
the reset token expires at 10:55pm local time on today's date. You can
generate a token that looks like
On Jun 28, 12:29 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> https://example.com/reset/34-7127f83ebf8ce7ed22bdc50a50572a30
>
> i.e.
>
> https://example.com/reset/{uid}-{hash}
I've been playing with this a bit and the one thing that was
concerning me is that the UID on large sites can end up
On Jun 28, 7:58 pm, "Adi J. Sieker" <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
> > That's absolutely ingenious - that approach gets my vote. I think I'll
> > switch DjangoPeople over to that.
>
> and to have the token expire you could add the date of the following day
> into the
Just a short question about coding style and possible shortcuts for
django-users. I know this is a very minor issue, but I'm just curious...
Currently there are some - I count eight - places where wraps() get
imported, they all look something like:
On Sat, 28 Jun 2008 09:18:46 +0200, Simon Willison
<[EMAIL PROTECTED]> wrote:
> That's absolutely ingenious - that approach gets my vote. I think I'll
> switch DjangoPeople over to that.
and to have the token expire you could add the date of the following day
into the hash.
That way the
On Sat, 2008-06-28 at 06:12 -0700, ionut wrote:
> I do'nt consider to be a MVC good pattern rendering form html inside
> newforms class.
A form class is purely presentational, so there's no "MVC" (or whatever
you might want to call it -- you can't do MVC on the web, after all)
violation going
I do'nt consider to be a MVC good pattern rendering form html inside
newforms class.
I think a better proach while rendering html forms is to use a
template file
A proff of concept:
class BaseForm(StrAndUnicode):
...
def __unicode__(self):
t = get_template('default_form.html')
>
> The one slight issue
> is that if the user picks the same password (or ever does so in the
> future) then the hash could become the same again,
>
I don't think that's true, at least using django.contrib.auth. The salt is
re-generated whenever the password is changed, so the odds of the user
On Saturday 28 June 2008 01:39:26 Scott Moonen wrote:
> > The problem with this is it requires state on the server, which
> > means . . .
>
> I don't think it's necessary to implement this in such a way that
> additional server state is stored. Instead, you could let the
> confirmation token be
On Fri, Jun 27, 2008 at 5:41 PM, David Reynolds
<[EMAIL PROTECTED]> wrote:
> Running with mysql backend created a few errors (I'm not sure if
> they're related so I've attached them in full, hope that's ok):
Hi David,
Thanks for doing this testing, but from the look of it, these errors
are all
On Fri, Jun 27, 2008 at 4:33 PM, Antonis Christofides
<[EMAIL PROTECTED]> wrote:
> There are essentially two things that you can do with a block:
> (1) define it (or redefine it); and (2) insert it somewhere in a
> template. The block tag thus performs different functions depending
> on
Malcolm Tredinnick napsal(a):
>
> On Wed, 2008-06-25 at 11:54 +0200, Tomas Kopecek wrote:
>> Hello,
>> In django.utils.synch is located RWLock. When you try enter the same
>> lock twice (probably in some subprocedure) you can't. I think that
>> correct semantics is that you had acquired this
On Jun 28, 1:39 am, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> I don't think it's necessary to implement this in such a way that additional
> server state is stored. Instead, you could let the confirmation token be a
> hash of the internal user state -- including, most importantly, the user
>
19 matches
Mail list logo
