Re: delegating our static file serving

Hi Aleksej, Thanks for your work on this, and sorry I haven't replied sooner -- just been busy with lots of other things ;) My plan for integrating WhiteNoise was actually to merge it in as part of contrib.staticfiles and basically stop development on it as an independent project. When I first

Re: delegating our static file serving

I think there is no need to vendor nowadays, we can just depend on whitenoise. (like we do for pytz) On Wednesday, March 22, 2017 at 5:14:58 PM UTC+1, Aleksej Manaev wrote: > > Am I on the right track with the integration of WhiteNoise into Django? > Can Someone lead me to the next steps that ne

Re: delegating our static file serving

Am I on the right track with the integration of WhiteNoise into Django? Can Someone lead me to the next steps that need to be done? https://github.com/django/django/compare/master...AleksejManaev:ticket_27325?expand=1 I think "django/views/static.py" can't be deprecated because it is used for p

Re: delegating our static file serving

I started looking into this but have progressed slowely. At first I put the whitenoise project into the contrib folder of django. Tim Graham suggested not to change much of the integration with the old WSGI interface, so I think the new middleware way would be alright too. On Tuesday, 29 Decem

Re: delegating our static file serving

If you need some help, I'm as available as I can be. Em ter, 20 de dez de 2016 19:50, David Evans escreveu: > I've been intending to work on this for a while (as the original author of > WhiteNoise it would make the most sense for me to do the integration work) > but as ever the problem has been

Re: delegating our static file serving

I've been intending to work on this for a while (as the original author of WhiteNoise it would make the most sense for me to do the integration work) but as ever the problem has been finding the time. I've been hoping to make some progress on this over the Christmas period, but we'll see what ha

Re: delegating our static file serving

I'm willing to cooperate on this one. Anyone is working on this and need help? -- 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

Re: delegating our static file serving

Hi, I don't know of any updates on this issue outside of this thread. I think you could read through the thread and summarize the problems and possible solutions just as well as I could. The solution might involve integrating whitenoise in Django, as well an adding some enhancements. The whiten

Re: delegating our static file serving

Hello, I would like to work on this in the scope of my study project. Is someone already working on this? I am fairly new to contributing to the framework, can you provide me more information on the current state of the issue, which problems need to be solved and which possible solutions there a

Re: delegating our static file serving

Hello Curtis and Fabio, You can have a look at django- private-media, which implement a private storage engine : https://github.com/RacingTadpole/django-private-media Basic usage : > from private_media.storages import PrivateMediaStorage class Car(models.Model): > photo = models.ImageFie

Re: delegating our static file serving

I should probably finish off my toy working on the same lines... but introducing my earlier comments about per-source paths and permissions mixins... Very much a WIP, but I'm sure you'll see the idea: https://gist.github.com/funkybob/a89c10e24716a4ce55cf -- C On 18/01/16 09:58, Gordon wrote:

Re: delegating our static file serving

I put together a simple django middleware based off the functionality of whitenoise except that it uses the staticfiles storage for finding/serving files. I am sure there are lots of improvements to be made on it but it demonstrates using the filestorage api to accommodate remote static files.

Re: delegating our static file serving

Apologies if this has already been mentioned but I read this thread in full awhile ago and now everything is collapsed. If staticfiles serving is brought into django proper it would be nice if the storage api was used so that staticfiles can be stored remotely. I just ran into this looking at

Re: delegating our static file serving

I've just pushed a simple middleware wrapper that lets you install WhiteNoise by adding: MIDDLEWARE_CLASSES = ( ... 'whitenoise.middleware.StaticFilesMiddleware', ... ) See: https://github.com/evansd/whitenoise/blob/master/whitenoise/middleware.py No messing with wsgi.py! This appro

Re: delegating our static file serving

Hello Collin, > On 31 déc. 2015, at 23:44, Collin Anderson wrote: > > I feel like the insecure flag could get renamed to inefficient or something > like that. This view is insecure for serving user-uploaded files, for reasons Florian hinted at. Browsers “helpfully” get a lot things wrong for

Re: delegating our static file serving

On 01/01/16 15:49, Fabio Caritas Barrionuevo da Luz wrote: 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 cont

Re: delegating our static file serving

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

Re: delegating our static file serving

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

Re: delegating our static file serving

2015-12-31 12:52 GMT+01:00 Anssi Kääriäinen : > 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 clear

Re: delegating our static file serving

>>Anything that improves the development experience for tiny sites gets >>a big +1 from me. As a solo developer that usualy deploy a diferent application every 3 weeks or so, cant agree more. Big +1 for me too. -- You received this message because you are subscribed to the Google Groups "Djang

Re: delegating our static file serving

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. If you have a site where traffic is less than one hit per minute, you shouldn't care about performance that much. With Django, it is pretty

Re: delegating our static file serving

> On 29 Dec 2015, at 01:36, Tim Graham wrote: > > I'd like to work together with Dave to develop a proof of concept that > integrates whitenoise into Django. I spent about an hour looking through > whitenoise and our own static file serving code, and I think integrating > whitenoise will yiel

Re: delegating our static file serving

You are free to use what your PaaS provider supplies, but if you are using heroku (and many others) you do not have a choice. If AWS allows you to use apache 2.4 in event mode, then by all means use it! But there are plenty of platforms out there where you cannot easily serve static files and/or

Re: delegating our static file serving

Just curious, about PaaS, I know AWS (Amazon) deploys python/django on apache (which is quite decent), and apache also serves static files decently. What would be wrong with this? The idea of having Python serving static files (and potentially gziping it), when python is one of the slowest langu

Re: delegating our static file serving

Also consider the media files could number into the millions (or bajizillions?). Particularly for, say, a image hosting application. Clearly it would not be feasible to enumerate all the files, and there would clearly be regular additions. It might be that this use case is simply "beyond the sc

Re: delegating our static file serving

Also consider the media files could number into the millions (or bajizillions?). Particularly for, say, a image hosting application. Clearly it would not be feasible to enumerate all the files, and there would clearly be regular additions. It might be that this use case is simply "beyond the sc

Re: delegating our static file serving

On Tuesday, December 29, 2015 at 6:31:02 PM UTC+1, David Evans wrote: > > 2. Serving media files is a slightly different case. WhiteNoise was > designed around the assumption that it's serving a set of > developer-supplied, public files which remain unchanged during the lifetime > of the proce

Re: delegating our static file serving

I'd be very happy to help with this. Two things to mention: 1. When I first wrote WhiteNoise the FileResponse class didn't exist and so the only way I could access `wsgi.file_wrapper` was by wrapping the wsgi application directly and bypassing Django. Now we have the FileResponse class it would

Re: delegating our static file serving

I'd like to work together with Dave to develop a proof of concept that integrates whitenoise into Django. I spent about an hour looking through whitenoise and our own static file serving code, and I think integrating whitenoise will yield a simpler user experience with about the same amount of

Re: delegating our static file serving

On Friday, 5 December 2014 19:14:29 UTC, Carl Meyer wrote: > > On 12/04/2014 10:33 PM, Collin Anderson wrote: > > Hi All, > > > > I'm pretty interested in getting secure and _somewhat_ efficient static > > file serving in Django. > > > > Quick history: > > 2005 - Jacob commits #428: a "stati

Re: delegating our static file serving

On 12/04/2014 10:33 PM, Collin Anderson wrote: > Hi All, > > I'm pretty interested in getting secure and _somewhat_ efficient static > file serving in Django. > > Quick history: > 2005 - Jacob commits #428: a "static pages" view. Note that this view > should only be used for testing!" > 2010 -

Re: delegating our static file serving

+1 to this: I'm all in favour of supporting production-adequate static file handling in core. A couple of small points: We already have the views, api, and logic around for finding and serving > the correct files. One question that needs to be thought through is the role of `collectstatic` and

Re: delegating our static file serving

Requiring fewer moving parts for small sites is definitely an improvement. +1 to Collin's plan. Regards, Michael Manfre On Fri, Dec 5, 2014 at 2:02 AM, Loïc Bistuer wrote: > I'm +1 on this plan, "native" support for wsgi.file_wrapper makes a lot of > sense. > > -- > Loïc > > > On Dec 5, 2014, a

Re: delegating our static file serving

I'm +1 on this plan, "native" support for wsgi.file_wrapper makes a lot of sense. -- Loïc > On Dec 5, 2014, at 12:33 PM, Collin Anderson wrote: > > Hi All, > > I'm pretty interested in getting secure and _somewhat_ efficient static file > serving in Django. > > Quick history: > 2005 - Jaco

Re: delegating our static file serving

Yes, I support this plan. "Serve your files with nginx!" doesn't fly in the age of PaaS. Serving static files with Django and having a CDN cache them is a reasonable setup as far as I know. I don't know if the "probably insecure" argument still holds. Are there some specific security risks in se

Re: delegating our static file serving

Hi All, I'm pretty interested in getting secure and _somewhat_ efficient static file serving in Django. Quick history: 2005 - Jacob commits #428: a "static pages" view. Note that this view should only be used for testing!" 2010 - Jannis adds staticfiles. Serving via django is considered "gross

Re: delegating our static file serving

It's worth flagging up that part of what makes WhiteNoise good for serving static files in production also makes it not quite as good for using in development. Most file servers work by taking the requested URL, constructing a local path from it, and then checking whether a file exists at that

Re: delegating our static file serving

Hi All, I think doing something here is really good idea. I'm happy with any of the solutions mentioned so far. My question is: what does static/dj-static do that our built-in code doesn't do? What makes it more secure? It seems to me we're only missing is wsgi.file_wrapper and maybe a few mor

Re: delegating our static file serving

> On 28 Nov 2014, at 15:15, Tim Graham wrote: > > Berker has worked on integrating gunicorn with runserver so that we might be > able to deprecate our own homegrown webserver. Windows support for gunicorn > is supposedly coming soon which may actually make the idea feasible. This way > we pro

Re: delegating our static file serving

On 11/28/2014 07:15 AM, Tim Graham wrote: > Berker has worked on integrating gunicorn with runserver > so that we might be able to > deprecate our own homegrown webserver. Windows support for gunicorn is > supposedly coming soon >

delegating our static file serving

Berker has worked on integrating gunicorn with runserver so that we might be able to deprecate our own homegrown webserver. Windows support for gunicorn is supposedly coming soon which may actually make