A question: are there any plans to also improve MEDIA files (user uploaded files) in any foreseeable future?
Perhaps this is outside the scope of Django, but I believe Django could provide by default, any option to get a little more control over who can and can not access the MEDIA files. Most Django deployment tutorials with Nginx and Apache that saw out there do not say anything on the issue of data security. I believe it is a common use case, that not every file sent by a User should be available and accessible to anyone on the web. Out there, I found these two implementations: https://github.com/benoitbryon/django-downloadview https://github.com/johnsensible/django-sendfile -- Fábio C. Barrionuevo da Luz Palmas - Tocantins - Brasil - América do Sul http://pythonclub.com.br/ Em quinta-feira, 31 de dezembro de 2015 19:44:01 UTC-3, Collin Anderson escreveu: > > I'm still +1 to django providing a good file solution, whether it be > whitenoise, dj-static, or whatever. > > Here's all I came up with the last time I looked into this. It basically > involves passing insecure=True into our current code and sending cache > headers. (I feel like the insecure flag could get renamed to inefficient or > something like that.) I feel like the code we have really isn't all that > bad. Using something like whitenoise or dj-static allows you to bypass > middleware, which can really improve performance (if you have inefficient > middleware installed), but on the other hand, some people may want to use > the currently logged in user to determine whether or not to serve the file. > > Collin > > import re > > from django.conf import settings > from django.conf.urls import url > from django.contrib.staticfiles.views import serve as static_serve > from django.core.exceptions import ImproperlyConfigured > from django.views.decorators.cache import cache_control > from django.views.static import serve > > > def static(prefix, view=serve, **kwargs): > if not prefix: > raise ImproperlyConfigured("Empty static prefix not permitted") > if '://' in prefix: > return [] > if not settings.DEBUG: > view = cache_control(max_age=86400 * 30)(view) > return [ > url(r'^%s(?P<path>.*)$' % re.escape(prefix.lstrip('/')), view, > kwargs=kwargs), > ] > > urlpatterns = static(settings.STATIC_URL, view=static_serve, insecure=True > ) > > if settings.MEDIA_URL and settings.MEDIA_ROOT: > urlpatterns += static(settings.MEDIA_URL, document_root=settings. > MEDIA_ROOT) > > > On Thursday, December 31, 2015 at 7:42:54 AM UTC-5, Aymeric Augustin wrote: >> >> 2015-12-31 12:52 GMT+01:00 Anssi Kääriäinen <[email protected]>: >> >>> In my opinion one of the most important goals for Django is to make >>> deploying tiny projects securely and easily a trivial matter. We >>> aren't there right now. >>> >> >> +1 >> >> I'm maintaining three such sites (my wife's, my consultancy's and mine). >> I'm >> clearly not going to bother configuring a CDN. I deployed them with >> whitenoise >> — which isn't nearly as well known as it should be. If I hadn't known >> about >> it, I suspect I would have rolled a poor man's solution to serve static >> files >> in Python, because that's the easiest when deploying to a PaaS. >> >> Regarding the question of media files raised earlier in this thread, I >> think >> we shouldn't attempt to cache all existing files on start-up because even >> small sites could easily have tens of thousands e.g. a forum that stores >> users' avatars. We should look up the file at each query, which will be >> slightly less efficient, but functional and not subject to scalability >> issues. >> >> For both static and media files, we care about simplicity and security. It >> appears that whitenoise gives us great performance for static files as >> well, >> which is good. If we can't have it for media files, it's still fine. >> >> -- >> Aymeric. >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6b3b995c-ca28-4a61-a8b6-023314ca8b70%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
