On Nov 20, 1:41 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > i know that django is not recommended to serve static content via
> > django and the web server handler should be used for it.
>
> > also, the following method to serve static content in development env,
> > but not recommended in a production env.
>
> > django.views.static.serve
>
> >http://docs.djangoproject.com/en/dev/howto/static-files/?from=olddocs
>
> > my requirement is that I need to serve just one 10x10 gif file via
> > django -- so that i can track what users requested the file. can i use
> > the above view to serve this file ? what are the drawbacks of using
> > this view in a production env ?
>
> It's not like the Django thought-police will beat down your door in the
> middle of the night if you *do* serve a single piece of static content.
> But you should carefully read the warnings in the documentation about
> serving static files before deciding to do so.
>
> The drawbacks are that the Django web servers aren't designed to the
> same rigorous security standards that are applied to production web
> servers like Apache and lighthttpd,
I really scratch my head when I keep seeing this argument about
security. It doesn't really matter whether you use Apache or Django,
it is possible to screw up in configuring either such that you could
expose more of the file system than you intended.
The issue as to whether one is worse than the other has probably more
to do with how easy it is to also inadvertently turn on automatic
directory indexes thereby allowing arbitrary browsing rather than
having to guess what files may be available.
In Django one has to consciously set show_indexes parameter to True
for the particular urlconf rule. In this respect Apache is actually
more dangerous as stuff like DirectoryIndex will be inherited
automatically from an outer scope, so if someone is stupid enough to
have turned it on in main Apache server configuration scope, it will
then apply to all directories and that that is occurring wouldn't be
obvious.
Do acknowledge that with Apache 'Allow from all' also needs to be set
for appropriate scope, but a few too many times I have seen people do
exactly this in main Apache server configuration scope, or for whole
file system. Seems to be more prevalent amongst PC users who open up
their whole drive because they simply don't understand Apache
configuration enough to know to only apply it to certain contexts.
People turning on FollowSymLinks for whole server is also something
that see a bit too often.
So, in the hands of someone who doesn't know what they are doing, I
would almost say that one could cause bigger problems with Apache than
what could be done in the more constrained use case for serving static
files in Django.
I would also say that the bigger problem with people using Django with
Apache is those people who think they need to stick their Django site
instance somewhere under the Apache DocumentRoot for it to work. This
is a much worse situation because if DocumentRoot is still used to
serve static files, they could then be exposing all the Django site
code, including database passwords for download.
> and won't be (quite) as efficient.
> The efficiency probably won't matter for a (one-pixel?) graphics.
Hopefully static file serving in general will be better in Django 1.1.
See View-03 in:
http://code.djangoproject.com/wiki/Version1.1Features
Graham
> Whether what the Django server *does* provide is sufficiently secure for
> your needs only you can decide. But you can't say you weren't warned if
> everything goes pear-shaped ;-)
>
> regards
> Steve
> --
> Steve Holden +1 571 484 6266 +1 800 494 3119
> Holden Web LLC http://www.holdenweb.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
