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 05/12/2011 08:04 PM, Russell Keith-Magee wrote:
I suspect the answer will lie somewhere between get_prep_value() and
to_python() on DecimalField, but you'll need to do some code path
tracing to confirm. Looking at the code, I'm a little surprised that
it doesn't work as is...
Yours,
Russ Mag
Hi Michal,
I'm looking forward to seeing this project take shape! Comments below:
On 05/12/2011 06:41 AM, Michal Petrucha wrote:
[..]
> The constructor of a CompositeField will require at least two
> positional parameters, each positional parameter will be a single
> atomic field. The order of th
On Fri, May 13, 2011 at 12:08 AM, Shawn Milochik wrote:
> On 05/11/2011 08:00 PM, Russell Keith-Magee wrote:
>>
>> On Thu, May 12, 2011 at 3:35 AM, Shawn Milochik
>> wrote:
>>>
>>> Someone on django-users just commented that they set a default value on a
>>> DecimalField as a float, and were surp
On Fri, May 13, 2011 at 7:45 AM, Camilo Nova wrote:
> Hi all,
>
> Were im working we usually take in mind that fields in web forms
> should have a max length value for input, and we apply them well in
> cases like:
>
> username = forms.CharField(
> max_length=30,
> )
>
> But in cases
Hi all,
Were im working we usually take in mind that fields in web forms
should have a max length value for input, and we apply them well in
cases like:
username = forms.CharField(
max_length=30,
)
But in cases like:
cash = forms.IntegerField(
min_value=0,
ma
On 05/11/2011 08:00 PM, Russell Keith-Magee wrote:
On Thu, May 12, 2011 at 3:35 AM, Shawn Milochik wrote:
Someone on django-users just commented that they set a default value on a
DecimalField as a float, and were surprised when they were unable to create
a queryset using a float to find record
On Thu, May 12, 2011 at 8:49 AM, Tom Evans wrote:
> unique/unique_together: They should both be supported. unique_together
> should raise a PendingDeprecationWarning, and it should disappear
> according to the deprecation timeline. unique_together only exists as
> a Meta option as there is no fiel
On Thu, May 12, 2011 at 02:49:03PM +0100, Tom Evans wrote:
> Hi Michal
>
> This looks really, really good. A few comments:
Thanks for the response.
> Value of a composite field: It should descend from namedtuple. From
> 1.4 onwards, Django only supports 2.5+, so it's not necessary to fudge
> thi
On May 11, 9:47 pm, Mathieu AGOPIAN wrote:
> Just to make sure i've understood the topic here: you need to change
> MAX_SHOW_ALL_ALLOWED, but only for a specific model?
>
> Otherwise you could just add something like that to, say, the root urlconf:
>
> from django.contrib.admin.views import main a
On Thu, May 12, 2011 at 12:41 PM, Michal Petrucha
wrote:
> As most of you have probably noticed by now, in a week and a half I'll
> start working on the implementation of composite fields. Before that
> we should probably agree on the final form of the API.
>
>
Hi Michal
This looks really, real
Hi Bruno --
I'm sorry, but we can't help you here. This mailing list is for
discussion of developing Django itself, not user questions.
The django-users group is the right forum for questions like yours,
and I think you'll find an answer if you direct this question over
there.
Thanks!
Jacob
--
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
As most of you have probably noticed by now, in a week and a half I'll
start working on the implementation of composite fields. Before that
we should probably agree on the final form of the API.
This lengthy mail is mostly a recapitulation of things mentioned in
the past, like [1], [2], [3] and qu
Hi all,
i am writing some tests to test a RESTful api i have written
(Django 1.3, using piston, python 2.6.5).
The url is basically: /api/products and you need to be logged to
access it.
We can use such api, via curl PUT query (the client code uses pycurl
to access the ws).
It works in prod
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
20 matches
Mail list logo
