3 ms·

Tools like Apache and nginx are not ONLY faster at serving files with less load on the system than a script. They are also more thoroughly audited and battle-te

Tools like Apache and nginx are not ONLY faster at serving files with less load on the system than a script. They are also more thoroughly audited and battle-tested. And their declarative configs won't go wrong just because the person writing them missed an unbelievably subtle corner case introduced by using a Turing-complete language. It's important because there are so many opportunities for error in serving arbitrary files out of a filesystem with some rough and ready script. For example, if you are serving files out of the same filesystem that holds your configs and secret keys then you should be a bit nervous. You have to get the permissions right and make sure you don't have anything improper under a directory which you are publishing as a whole. If your users are uploading files to the same place you should feel really nervous. There are too many easy ways for people to be negligent and screw this up. In the context of designing an opinionated framework, you accept a lot of social liability and you are really dropping the ball if you are setting up tired and ignorant users to screw up this badly, without even a warning in the docs to think about what you are doing. With n script languages and m static file serving implementations per language, there are now (n*m) obscure packages to audit. Not counting their combinations... Your idea to just "fix the insecurity" and remove any warning from the docs means to do things which you merely believe to fix the insecurity, and then overlook the underlying risks of the approach. I am also not sure you are right when you suggest that there cannot be any performance (or reliability) impact of pushing static serving into some script library. Just as these are not audited they are also not nearly as likely to be benchmarked and tuned. If there is a reason to serve static files out of script, that reason will be because of some positive reason (like convenience or the need for some particular flexibility) rather than some vague sense that using Apache is "obsolete".

gojomo 14y ago
Here's the thing: Django makes the standard staticfiles app available. It's a great convenience, eliminating extra steps (collecting/moving static assets) and processes (another nginx/etc). And many projects' 'dev'/prototype incarnations are already open to the world, in one way or another. So if this is a security sin, they've already encouraged its widespread commission. A bit of "don't do this" or "don't do this in production" hand-waving in the docs don't resolve a security problem, if there's a real vulnerability in the current implementation. On the other hand, committing to the idea that the bundled staticfiles app may be used this way -- that in fact it's a good and modern way to operate, in production, once you have an inbound proxy cache -- would mean accepting deeper responsibility. It would give up the hedge, "if there's a security bug, we warned you!". It's not taking on n*m obligations: it's taking on 1 language, 1 module. And it's not even a new module or an obscure need... it's exactly the sort of thing an opinionated framework can solve for people. The old opinion -- "take this risk in development, but by the time you get to production use the 'best practice' of a separate static server" -- should be updated to a new opinion -- "the 'best practice' is now a front-end proxy cache, which makes the performance benefits of an extra static server negligible, so we're no longer going to assume everyone will do that in production". An admonition against using other less-tested code to achieve the same effect would still be appropriate. But not nonspecific FUD about the framework's own code -- that it is "probably insecure". Anything that's truly "probably insecure" ought to be fixed.
- St-Clock 14y ago
  "eliminating extra steps (collecting/moving static assets)" Interestingly, we extended the collectstatic command in many ways to perform minification, combination of assets, generation of sass and javascript variables (based on settings in python), etc. It's part of our deployment and if we were serving static files through django, we would still have to run a similar command. I'm also happy that nginx is handling file uploads, aliasing, redirection, virtual hosting on different IPs and Ports with different access control, real ip extraction (when behind a load balancer), etc. I'll be following more closely this trend of moving static asset hosting from a regular web server to the application container, but I believe that web servers like nginx and apache can do a lot more than just serving static files (at least, in complex deployment scenarios).
  - gojomo 14y ago
    That's certainly a value of a 'project prep step' (whether it involves static export or not). Not also, though, that a service like CloudFlare now puts some of these optimizations (minification, asset-combination, obfuscation, etc) into the cache layer, as optional cloud 'app' services to be enabled/disabled/paid-for as desired. Not saying that way is better for all, but it has potential as a convenience for some, getting those same expert-level optimization benefits while retaining a simple project/deployment structure.
- yummyfajitas 14y ago
  You are correct that the Django folks should be a little more careful with the staticfiles app. But I disagree with you that the best practice should change from a static server to a front-end proxy cache. Rather, the best practice should consist of using both. An important concept in security is deperimeterisation- the idea that you shouldn't assume you have a fixed border, inside of which is secure. So by all means, use a front-end proxy cache. But also put some effort into hardening your individual servers, treating them as if they will be operating under a full load.
peterbe 14y ago
The point was that; what difference does it make if Apache/Nginx is better when it's only doing it once. Or, more specifically, once per revision of the code.

gojomo 14y ago

Here's the thing: Django makes the standard staticfiles app available. It's a great convenience, eliminating extra steps (collecting/moving static assets) and processes (another nginx/etc). And many projects' 'dev'/prototype incarnations are already open to the world, in one way or another. So if this is a security sin, they've already encouraged its widespread commission. A bit of "don't do this" or "don't do this in production" hand-waving in the docs don't resolve a security problem, if there's a real vulnerability in the current implementation. On the other hand, committing to the idea that the bundled staticfiles app may be used this way -- that in fact it's a good and modern way to operate, in production, once you have an inbound proxy cache -- would mean accepting deeper responsibility. It would give up the hedge, "if there's a security bug, we warned you!". It's not taking on n*m obligations: it's taking on 1 language, 1 module. And it's not even a new module or an obscure need... it's exactly the sort of thing an opinionated framework can solve for people. The old opinion -- "take this risk in development, but by the time you get to production use the 'best practice' of a separate static server" -- should be updated to a new opinion -- "the 'best practice' is now a front-end proxy cache, which makes the performance benefits of an extra static server negligible, so we're no longer going to assume everyone will do that in production". An admonition against using other less-tested code to achieve the same effect would still be appropriate. But not nonspecific FUD about the framework's own code -- that it is "probably insecure". Anything that's truly "probably insecure" ought to be fixed.

St-Clock 14y ago
"eliminating extra steps (collecting/moving static assets)" Interestingly, we extended the collectstatic command in many ways to perform minification, combination of assets, generation of sass and javascript variables (based on settings in python), etc. It's part of our deployment and if we were serving static files through django, we would still have to run a similar command. I'm also happy that nginx is handling file uploads, aliasing, redirection, virtual hosting on different IPs and Ports with different access control, real ip extraction (when behind a load balancer), etc. I'll be following more closely this trend of moving static asset hosting from a regular web server to the application container, but I believe that web servers like nginx and apache can do a lot more than just serving static files (at least, in complex deployment scenarios).
- gojomo 14y ago
  That's certainly a value of a 'project prep step' (whether it involves static export or not). Not also, though, that a service like CloudFlare now puts some of these optimizations (minification, asset-combination, obfuscation, etc) into the cache layer, as optional cloud 'app' services to be enabled/disabled/paid-for as desired. Not saying that way is better for all, but it has potential as a convenience for some, getting those same expert-level optimization benefits while retaining a simple project/deployment structure.
yummyfajitas 14y ago
You are correct that the Django folks should be a little more careful with the staticfiles app. But I disagree with you that the best practice should change from a static server to a front-end proxy cache. Rather, the best practice should consist of using both. An important concept in security is deperimeterisation- the idea that you shouldn't assume you have a fixed border, inside of which is secure. So by all means, use a front-end proxy cache. But also put some effort into hardening your individual servers, treating them as if they will be operating under a full load.

peterbe 14y ago

The point was that; what difference does it make if Apache/Nginx is better when it's only doing it once. Or, more specifically, once per revision of the code.