> int(time.time()) == 1305761382
> base62.encode(1305761382) == '1QMqBS'
> base62.encode(1305761382) == 'KgwVC'
Oops! meant to say
base62.encode(305761382) == 'KgwVC'
-Paul
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
>> Baseconv is a clever bit of work. It should probably be using our full
>> base64 charset. We could also shave some digits in the time-limited
>> output there by subtracting from a more recent fixed value than the
>> unix epoch, the way the password reset token code does.
>
> The TimeStampSigner
On 18.05.2011, at 20:19, Jannis Leidel wrote:
> On 13.05.2011, at 07:33, Paul McMillan wrote:
>
>> Baseconv is a clever bit of work. It should probably be using our full
>> base64 charset. We could also shave some digits in the time-limited
>> output there by subtracting from a more recent fixed
On 13.05.2011, at 07:33, Paul McMillan wrote:
> Baseconv is a clever bit of work. It should probably be using our full
> base64 charset. We could also shave some digits in the time-limited
> output there by subtracting from a more recent fixed value than the
> unix epoch, the way the password rese
Also, regarding the note about not echoing back the expected value
even during debug (line 156 of signing.py):
Do it the same way as it is with the auth tokens, compute the expected
value inline without assigning it to a variable.
http://code.djangoproject.com/browser/django/trunk/django/contrib/
> Yeah, SHA256 and SHA512 have the downsides of being rather long for
> the type of application the signatures are going to be used for,
> e.g. one-time URLs.
That's fair. SHA1 is moving towards broken, but HMAC currently covers
that gap. Shorter is certainly a feature we want here.
> If I read t
On 12.05.2011, at 14:17, Paul McMillan wrote:
> I'd also like to review this in depth before it gets committed, but
> won't have a chance to do that for a day or two.
>
> I agree with Luke re: salted hmac.
>
> A couple of initial thoughts:
>
> Since we aren't supporting Python 2.4 anymore, we
On 12.05.2011, at 01:05, Luke Plant wrote:
> On 11/05/11 20:20, Jannis Leidel wrote:
>> Hi all,
>>
>> This is in continuation to Simon's previous efforts about adding tools
>> for easy signing, including secure cookies ([1], [2]).
>>
>> Stephan (who is working on #9200 [3] -- improving the wizar
Luke Plant wrote:
So I feel quite strongly that we should fix this code to use
salted_hmac. (Or fix salted_hmac if there is some problem with it, but
remembering that there is lots of data that depends on it).
I updated the patch and changed the way the hashes are generated. We now use
the sal
I'd also like to review this in depth before it gets committed, but
won't have a chance to do that for a day or two.
I agree with Luke re: salted hmac.
A couple of initial thoughts:
Since we aren't supporting Python 2.4 anymore, we have access to
hashlib. We should use SHA256 or 512.
Since the
On 12.05.2011, at 01:05, Luke Plant wrote:
> On 11/05/11 20:20, Jannis Leidel wrote:
>> Hi all,
>>
>> This is in continuation to Simon's previous efforts about adding tools
>> for easy signing, including secure cookies ([1], [2]).
>>
>> Stephan (who is working on #9200 [3] -- improving the wi
On 11/05/11 20:20, Jannis Leidel wrote:
> Hi all,
>
> This is in continuation to Simon's previous efforts about adding tools
> for easy signing, including secure cookies ([1], [2]).
>
> Stephan (who is working on #9200 [3] -- improving the wizard in
> contrib.formtools) and me just updated the pa
Hi all,
This is in continuation to Simon's previous efforts about adding tools
for easy signing, including secure cookies ([1], [2]).
Stephan (who is working on #9200 [3] -- improving the wizard in
contrib.formtools) and me just updated the patch attached to ticket
#12417 [4] with the recommended
13 matches
Mail list logo
