Re: #12180: Test case advice

[Shai Berger]

Hi,

On Sunday 28 November 2010, Christophe Pettus wrote:
> 
> I'm updating the patch for #12180 to work with the dev version of 1.3, and
> preparing a test case for it.  Being new to the Django test suite, it's
> not clear to me how to introduce a backend-specific and
> settings-file-specific test (the test case requires PostgreSQL 8.2+ and
> AUTOCOMMIT: True in the database options).  Is there some quick guidance
> from those more experienced than me?
> 
I'm not all that experienced, but my impression is that the Django test suite 
makes selective testing based not on the identity of the backend, but rather 
its features. This is expressed with decorators such as 
django.test.skipIfDBFeature/skipUnlessDBFearure. These are special cases of 
the more general unittest.skipIf and unittest.skipUnless.

However, looking at the bug, it seems like you require not only a backend-
specific test, but something more complex: You need a "fresh" connection. So 
what I think you should do, is:

- skipUnlessDBFeature('can_return_id_from_insert')
- in the test setup, manipulate settings.DATABASES to insert a new dictionary 
using the same details as 'default', and making sure AUTOCOMMIT is on
- make your insert query using= this new connection, so it is created for it.

One other point: There is a database feature named "uses_autocommit" -- 
currently it is false (by default) for postgresql_psycopg2, but if I 
understand correctly its true value depends on options. If it did reflect the 
options, you could have skipUnless'd it. I'm not sure if that would make your 
test better (you still need a fresh connection), but it may be worth opening 
its own ticket.

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Could the comments framework be more generic?

[Thejaswi Puthraya]

Hi,
I am the student who worked on improving the comments framework a
couple of years back and have been absconding since then ;-)
Personally, I would love to see the comments app out of contrib
because of the need to maintain backwards compatibility especially for
an app with very few users.

On Nov 28, 4:55 am, Kevin Renskers  wrote:
> 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 local database to do a count of comments, get
> the list of comments, etc.

Can you be specific on how the current setup is preventing you from
getting it done?

>
> If Django's comments framework would offer an API that is one level
> above the database models, we could write our own functions that
> implement getting comments, saving them, do a count of comments for
> the object, etc.

Apart from a model backend what other backends are we looking at to
store comments?

>
> I understand that a logical reaction to this suggestion would be to
> just not use Django's comments app, but roll my own. But I want to
> integrate the Disqus comments with existing apps, that already use
> Django's system to, for example, show the count of comments on blog
> articles in the admin interface. Django-blog-zinnia does this.
>
> I am looking forward to any comments and ideas. Is something like this
> even possible without completely breaking backwards compatibility?

If it is a clean proposal, it might be possible to convince the core
devs to break the backwards compatibility rule. You can count me in
for any kind of help regarding this task.

--
Cheers
Theju

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Could the comments framework be more generic?

[Kevin Renskers]

Whoops, url should be https://bitbucket.org/bolhoed/django_disqus_comments.

On Nov 28, 7:29 pm, Kevin Renskers  wrote:
> The existing apps use the JavaScript interface offered by Disqus. This
> does not integrate with apps that expect Django's comments app.
>
> I've made good progress on my comments app extension that uses Disqus,
> but now I am at a point where the models are working against me. Code
> is on bitbucket:http://bitbucket.org/bolhoed/django-disqus-comments/.
> I think that from this code the problem of the current situation is
> clear.
>
> I'd be more then happy to work on a new comments API for Django by the
> way!
>
> Kevin
>
> On Nov 28, 5:19 pm, "subs...@gmail.com"  wrote:
>
>
>
> > Heh, already put a few hours doing something like this. There's some
> > django-discus attempts out there--have you looked at them? I haven't
> > bothered to notice if any use the comments framework but it sure would
> > be handy to make comments out of discus or backtype feeds or variants
> > thereof.
>
> > But whether it was in trunk or just somewhere on github, I'd use it
> > either way. In my thinking about doing this I never really ran into a
> > compatibility/patch issue. Did you?
>
> > -Steve
>
> > On Nov 27, 6:55 pm, Kevin Renskers  wrote:
>
> > > 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 local database to do a count of comments, get
> > > the list of comments, etc.
>
> > > If Django's comments framework would offer an API that is one level
> > > above the database models, we could write our own functions that
> > > implement getting comments, saving them, do a count of comments for
> > > the object, etc.
>
> > > I understand that a logical reaction to this suggestion would be to
> > > just not use Django's comments app, but roll my own. But I want to
> > > integrate the Disqus comments with existing apps, that already use
> > > Django's system to, for example, show the count of comments on blog
> > > articles in the admin interface. Django-blog-zinnia does this.
>
> > > I am looking forward to any comments and ideas. Is something like this
> > > even possible without completely breaking backwards compatibility?
>
> > > Kind regard,
> > > Kevin Renskers

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

#12180: Test case advice

[Christophe Pettus]

Hi,

I'm updating the patch for #12180 to work with the dev version of 1.3, and 
preparing a test case for it.  Being new to the Django test suite, it's not 
clear to me how to introduce a backend-specific and settings-file-specific test 
(the test case requires PostgreSQL 8.2+ and AUTOCOMMIT: True in the database 
options).  Is there some quick guidance from those more experienced than me?

--
-- Christophe Pettus
   x...@thebuild.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[Ivan Sagalaev]

On 11/28/2010 10:13 AM, Russell Keith-Magee wrote:

For your consideration, I present a patch to resolve #12815 and
#12816, adding a TemplateResponse and a render() shortcut.


Thank you!


  - The render() shortcut doesn't use TemplateResponse. Since render()
and TemplateReponse() have exactly the same prototype, I didn't see
the value in adding a shortcut that just redirected to a different
constructor. However, there is still value in making an easy-to-use
render_to_response, for those situations where a TemplateResponse
can't be used.


I have a slight (about -0) concern about this… It might turned out as 
the same mistake that was made with render_to_response() in the first 
place: it wasn't powerful enough (i.e. it didn't use RequestContext) to 
be used as a default shortcut. If people would like TemplateResponse 
they would be frustrated that render() doesn't use it. Using 
TemplateResponse directly is perfectly possible but then we have to 
explain to every newcomer why are there two slightly different ways of 
doing one thing. I think that cases where one wants to care about using 
pure HttpResponse instead of TemplateResponse would be rare and it's 
better not be the default behavior.


P.S. Noticed a typo in the patch:

@@ -164,6 +154,13 @@
 urlresolvers.set_urlconf(None)

 try:
+# Apply template response middleware and the bake the response
+# if the response can be baked
+if hasattr(response, 'bake') and callable(response.bake):

The first line of the comment should be "and the*n* bake the response".

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Pluggable encryption for django auth (design proposal)

[Christophe Pettus]

On Nov 28, 2010, at 10:26 AM, Tom X. Tobin wrote:
> No, I'm not thinking of rainbow tables.  The key word here is
> *single*.  As I said before, a salt *does* help against an attacker
> trying to brute-force multiple passwords from your database, since he
> can't simply test each brute-force result against all your passwords
> at once; he has to start all over from scratch for every single
> password that has a different salt.  If he only cares about one
> *particular* account, the salt doesn't help, no.

Even in your scenario, it only helps as much as the entropy in the password 
selection.  If everyone has a unique password, it doesn't help at all 
(admittedly unlikely).  Again, it's a linear benefit, but not an exponential 
one.

Right.  So, about that proposal... :)

--
-- Christophe Pettus
   x...@thebuild.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Could the comments framework be more generic?

[Kevin Renskers]

The existing apps use the JavaScript interface offered by Disqus. This
does not integrate with apps that expect Django's comments app.

I've made good progress on my comments app extension that uses Disqus,
but now I am at a point where the models are working against me. Code
is on bitbucket: http://bitbucket.org/bolhoed/django-disqus-comments/.
I think that from this code the problem of the current situation is
clear.

I'd be more then happy to work on a new comments API for Django by the
way!

Kevin


On Nov 28, 5:19 pm, "subs...@gmail.com"  wrote:
> Heh, already put a few hours doing something like this. There's some
> django-discus attempts out there--have you looked at them? I haven't
> bothered to notice if any use the comments framework but it sure would
> be handy to make comments out of discus or backtype feeds or variants
> thereof.
>
> But whether it was in trunk or just somewhere on github, I'd use it
> either way. In my thinking about doing this I never really ran into a
> compatibility/patch issue. Did you?
>
> -Steve
>
> On Nov 27, 6:55 pm, Kevin Renskers  wrote:
>
>
>
> > 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 local database to do a count of comments, get
> > the list of comments, etc.
>
> > If Django's comments framework would offer an API that is one level
> > above the database models, we could write our own functions that
> > implement getting comments, saving them, do a count of comments for
> > the object, etc.
>
> > I understand that a logical reaction to this suggestion would be to
> > just not use Django's comments app, but roll my own. But I want to
> > integrate the Disqus comments with existing apps, that already use
> > Django's system to, for example, show the count of comments on blog
> > articles in the admin interface. Django-blog-zinnia does this.
>
> > I am looking forward to any comments and ideas. Is something like this
> > even possible without completely breaking backwards compatibility?
>
> > Kind regard,
> > Kevin Renskers

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Pluggable encryption for django auth (design proposal)

[Tom X. Tobin]

On Sun, Nov 28, 2010 at 12:11 PM, Christophe Pettus  wrote:
>> I'm not arguing that a salt helps against brute-forcing a *single*
>> password (it doesn't), but it does in fact help against someone trying
>> to brute-force your entire password database (or any subset of more
>> than one password), since each password with a different salt lies
>> within an entirely different space that must be brute-forced
>> separately from the rest.
>
> I'm not sure what you mean by the "space"; I think you are thinking of a 
> rainbow dictionary attack, where the hashes are precomputed; a salt does 
> indeed help (and probably blocks) that kind of attack.  In the case of a 
> straight brute-force attack or a standard dictionary attack without 
> precomputing, the only benefit of the salt is that it makes computing the 
> candidate hash a bit longer, based on the length of the salt.  It's a trivial 
> amount of time.
>
> Remember, it's extremely inexpensive to brute-force a single MD5 or SHA1 
> hash, and the salt does not make it appreciably more expensive.  If a CUDA 
> application can brute force 700 million MD5s per second, doubling the length 
> is not really going to make it any more secure.

No, I'm not thinking of rainbow tables.  The key word here is
*single*.  As I said before, a salt *does* help against an attacker
trying to brute-force multiple passwords from your database, since he
can't simply test each brute-force result against all your passwords
at once; he has to start all over from scratch for every single
password that has a different salt.  If he only cares about one
*particular* account, the salt doesn't help, no.

But regardless, I apologize for derailing this conversation so far off.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Unexpected behaviour when providing bad input to CheckboxInput

[Dan Fairs]

Hi,

I've come across some interesting behaviour if you intentionally supply bad 
data to a model formset whose forms use CheckboxInputs. Basically, it's 
possible to have custom validation code on the form class which ensures the 
boolean field's input is False, have this validation pass, but then the 
instance silently fails to save to the database when you call formset.save() 
when an instance's existing value is True.

The way to do this is to provide a '0' as input on the form submit, rather than 
omitting the field entirely, as a proper checkbox widget would do.

This is more easily explained with code:


class M(models.Model):
flag = models.BooleanField()


class DefaultModelForm(forms.ModelForm):
# This form will get an auto-generated BooleanField, which uses
# the CheckboxInput widget.
class Meta:
model = M

def clean(self):
# Now, because BooleanField.to_python knows about '0',
# cleaned_data actually contains False. '0' and '1' can
# be posted by RadioSelect widgets.
cleaned_data = super(DefaultModelForm, self).clean()
if cleaned_data.get('flag', None) != False:
raise ValidationError, u'Flag must be false!'
return cleaned_data


class SimpleTest(TestCase):

def setUp(self):
# Let's set up a signal handler so we can tell whether the model was 
saved.
self.save_count = collections.defaultdict(int)

def saved(sender, **kwargs):
self.save_count['count'] += 1
signals.post_save.connect(saved, sender=M, dispatch_uid='M')

self.m = M.objects.create(flag=True)

# Prove our plumbing works
self.assertEqual(1, self.save_count['count'])


def test_checkbox(self):
formset_class = forms.models.modelformset_factory(
M,
max_num=1,
form=DefaultModelForm
)

# Note that 'form-0-flag' being 0 is what a radio button
# would normally provide.
formset = formset_class({
'form-INITIAL_FORMS': '1',
'form-TOTAL_FORMS': '1',
'form-0-id': str(self.m.pk),
'form-0-flag': '0',
}, queryset=M.objects.all())

# Uh-oh - this now validates as True, because the BooleanField 
successfully
# parsed '0' as False, but the CheckboxWidget doesn't know what to do 
with
# '0'.
formset.is_valid()


# Since all the data looks OK, we go ahead and try to save. To compound
# the problem, the CheckboxWidget sees that the initial value from the
# model was True, and interprets '0' as bool('0') == True, so doesn't
# think that the data has changed. The model therefore never actually
# gets saved...
formset.save()

# If it saved properly, our save count should have gone up by one. 
Sadly,
# it didn't, so this test fails.
self.assertEqual(2, self.save_count['count'])

# So - despite is_valid() assuring us that all our data was OK, saving 
the
# model silently failed.

I've tried this with Django 1.2.3 and trunk r14735. 

I'm not quite sure what the bug is here, if there is one; but it seem wrong 
that you can write validation code that explicitly checks cleaned_data for a 
boolean to be False, have that validation pass, and then for the underlying 
model to not be saved when the formset save() is called.

(For the curious - we discovered this while writing tests for a Piston API that 
uses formsets to validate data, and accidentally passed a '0' instead of 
omitting the field in the test.)

Should I raise a bug for this one?

Cheers,
Dan
--
Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.com


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Pluggable encryption for django auth (design proposal)

[Christophe Pettus]

On Nov 27, 2010, at 10:29 PM, Tom X. Tobin wrote:
> The point is that I'm *not* assuming hardware of equivalent speed.
> I'm assuming that a worst-case attacker has hardware significantly
> faster than your webserver at their disposal, so I was curious if the
> purported benefit still held in that case.  Maybe it does; I don't
> know.

Well, yes, it does, for exactly the reason described: The application has to 
encode exactly one password; the attacker has to try billions in order to 
brute-force one.  If you assume, say, one password per week is the slowest 
practical attack, and if it takes 10ms to hash one password, the attacker's 
hardware has to be about 46,654 times more powerful than your web server.

> I'm not arguing that a salt helps against brute-forcing a *single*
> password (it doesn't), but it does in fact help against someone trying
> to brute-force your entire password database (or any subset of more
> than one password), since each password with a different salt lies
> within an entirely different space that must be brute-forced
> separately from the rest.

I'm not sure what you mean by the "space"; I think you are thinking of a 
rainbow dictionary attack, where the hashes are precomputed; a salt does indeed 
help (and probably blocks) that kind of attack.  In the case of a straight 
brute-force attack or a standard dictionary attack without precomputing, the 
only benefit of the salt is that it makes computing the candidate hash a bit 
longer, based on the length of the salt.  It's a trivial amount of time.

Remember, it's extremely inexpensive to brute-force a single MD5 or SHA1 hash, 
and the salt does not make it appreciably more expensive.  If a CUDA 
application can brute force 700 million MD5s per second, doubling the length is 
not really going to make it any more secure.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[sago]

*very nice* Russ. Congrats and thanks! Totally removes a wart I've
just got used to working around.

"bake" is a pretty universal verb for this, afaict. I wouldn't say it
was clever or new. "fry" however (in Jacob's post) was new to me and
required googling.

Ian.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Could the comments framework be more generic?

[subs...@gmail.com]

Heh, already put a few hours doing something like this. There's some
django-discus attempts out there--have you looked at them? I haven't
bothered to notice if any use the comments framework but it sure would
be handy to make comments out of discus or backtype feeds or variants
thereof.

But whether it was in trunk or just somewhere on github, I'd use it
either way. In my thinking about doing this I never really ran into a
compatibility/patch issue. Did you?

-Steve

On Nov 27, 6:55 pm, Kevin Renskers  wrote:
> 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 local database to do a count of comments, get
> the list of comments, etc.
>
> If Django's comments framework would offer an API that is one level
> above the database models, we could write our own functions that
> implement getting comments, saving them, do a count of comments for
> the object, etc.
>
> I understand that a logical reaction to this suggestion would be to
> just not use Django's comments app, but roll my own. But I want to
> integrate the Disqus comments with existing apps, that already use
> Django's system to, for example, show the count of comments on blog
> articles in the admin interface. Django-blog-zinnia does this.
>
> I am looking forward to any comments and ideas. Is something like this
> even possible without completely breaking backwards compatibility?
>
> Kind regard,
> Kevin Renskers

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Question on ImageField width_field/height_field motivations

[Jacob Kaplan-Moss]

On Sat, Nov 27, 2010 at 1:55 AM, Tim Diggins  wrote:
> 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 storage like django-storages.s3). Or have I
> missed something in the code?

Not really - it's just that this is one of the older and dustier
corners of Django. The original idea was that you (i.e. the user, not
the framework) would be responsible for using width_field and
height_field in your own code, and that going back to image.width and
image.height would be the way to force a recalculation. (A historical
note: before the file field refactoring, these were methods named
obj.get__width(), so the "I'm doing work" nature of 'em was
a bit more obvious).

I'm not sure it's worth changing, but a better note in the
documentation about the performance characteristics would be good I
think.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[Jacob Kaplan-Moss]

Hi Russ --

On Sun, Nov 28, 2010 at 1:13 AM, Russell Keith-Magee
 wrote:
> For your consideration, I present a patch to resolve #12815 and
> #12816, adding a TemplateResponse and a render() shortcut.

Good stuff.

A couple of things though:

* I'm really not a fan of "bake()" and ".baked" -- it really feels too
  clever a name to me. I know there's a bit of precedent w.r.t. "baked" and
  "fried" responses, but I still think the name's just non-obvious.
  Especially to people who don't speak English natively.

  Can we just go with something bording like "render()" and ".rendered"?

* I think we should deprecate render_to_response() in favor of render().
  render_to_response() is just render(request=None, ...), right? Any
  reason to keep both around?

Thanks!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.