On Mon, Aug 30, 2010 at 11:09 PM, dave b <db.pub.m...@gmail.com> wrote: >> I don't actually use Django so not 100% sure, but yes there possibly >> isn't an equivalent of LimitRequestBody definable within Django unless >> can be done with middleware. > > Ok so you don't even use django, ok... > You know I think I missed your presentation at pycon-au.
Whether Graham uses Django isn't especially relevant here. You've been making a bunch of claims about mod_wsgi and Apache behavior. Graham is most certainly an expert on those two tools. >> So, yes it may make sense for Django to have a fail safe and allow you >> to specify a maximum on upload size if it doesn't already, but that is >> only of use where you haven't set up your production web server >> properly to protect you from abuses, something you should be doing. > > Yes and imho it should be in django by default, not up to end django > users to figure out. > Secure by default please! That's an easy epithet to throw around, but I disagree that it is appropriate here. "Security" doesn't mean "stops the user from making mistakes". Also, consider this from a practical standpoint. If we introduced this setting, we would need to introduce it with a default value. If we set that limit to a low value (say, 10MB), lots of existing users would discover that their website suddenly stopped accepting files. If we set the value high (say 1GB), the attack still exists -- a malicious user could upload a series of 999MB files. The only truly backwards-compatibly option is to introduce the setting, but disable it by default (i.e., no size limit). However, this relys on people reading the documentation and determining an appropriate value for the setting -- at which point, we've just duplicated the functionality of Apache without actually changing anything. IMHO, Graham is completely right when he says that the webserver is the right place to catch this. Django isn't about to start introducing more settings to duplicate functionality that is better provided by other parts of the tool chain. This is not an isolated policy decision, either. For example, Django *could* provide a database connection pool -- but we have resolutely refused to do so, on the grounds that there are excellent third party tools that implement this functionality. Just because we *can* doesn't mean we *should*. That said, there has been discussion recently about adding a section to Django's docs talking about security issues -- things that may not be immediately obvious about project design and configuration, but would behoove users to think about. A discussion of this problem sounds like it would be a good addition. >> For the third time I ask you whether you have actually gone and tested >> your hypothesis and can provide a working test case that demonstrates >> the problem. > Ok. Look. You don't use django. > 1. Try this - go to the django website > http://docs.djangoproject.com/en/dev/intro/tutorial01/ > > 2. and follow the tutorial 1 (and also do 2 ) when it says put the > poll file like this: > from django.db import models > > class Poll(models.Model): > question = models.CharField(max_length=200) > pub_date = models.DateTimeField('date published') > > class Choice(models.Model): > poll = models.ForeignKey(Poll) > choice = models.CharField(max_length=200) > votes = models.IntegerField() > > put this instead: > > from django.db import models > import datetime > > class Poll(models.Model): > question = models.CharField(max_length=200) > pub_date = models.DateTimeField('date published') > filed = models.FileField(upload_to="tmp/") > def __unicode__(self): > return self.question > def was_published_today(self): > return self.pub_date.date() == datetime.date.today() > > > class Choice(models.Model): > poll = models.ForeignKey(Poll) > choice = models.CharField(max_length=200) > votes = models.IntegerField() > filed = models.FileField(upload_to="tmp/") > def __unicode__(self): > return self.choice > > Ok still following? Look -- Graham may not use Django on a daily basis, but he's not a fool. For the record, neither am I. A cursory examination of his history on this mailing list would indicate that saying "Add a FileField uploading to /tmp to an existing model" would be more than enough detail to describe your setup here. The part of this problem that you continue to refuse to describe is *THE ONLY PART THAT MATTERS* - the web server configuration that you're using to make your assertion. > well you finish the tutorial(s) now and then you try to upload a file right? > So you start uploading the file. Now because (I assume you are still > using the django built in webserver) why don't you play with this a > bit, start uploading say 10 1gb files(all at once) then stop them(all) > at around say 700mb~ in. > Have fun! (obviously you should go further than this and try with > apache setup etc.). The implication here is that you *haven't* tried this with Apache. Worse still, it sounds like you might be trying to use the Django development server as your test case to validate that this is a problem. If this is the case, I'm going to start ignoring this thread -- the development server *IS NOT* a production ready server [1], and *IS NOT* a useful indication of anything approximating real-world server behaviour, beyond the fact that it implements HTTP and WSGI. If you're trying to use the dev server as proof of anything at the server level, you're on your own. [1] http://docs.djangoproject.com/en/dev/ref/django-admin/?from=olddocs#runserver-port-or-ipaddr-port >> FWIW, there are much simpler ways to bring a site down than this. I >> suggest you go research Slowloris. > I know about this attack, but I can use my attack against those who > are not using apache. > What do you say to this ? I say that this is the reason we're getting frustrated. So far, you haven't actually told us which web server you *are* using. You keep alluding to this "not-apache" webserver, but you haven't actually said which webserver you *are* using. Apache has it's faults, but it is feature complete, battle hardened, widely available, and almost certainly the most widely used webserver for Django deployment. It's also the webserver that virtually every Django user and developer will have some experience in using. If a potential problem exists in at the server level, Apache is the best lingua franca to use in demonstrating it. If the problem is actually that you're using a custom HTTP server, and that custom HTTP server isn't providing a feature that you need (such as a way to reject large uploads), then my argument to you is that you need to get a better web server. Django isn't going to add features to compensate for inadequate HTTP servers -- especially when there are a wide range of HTTP servers out there that *do* provide a full feature set. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
