Appengine: Django static serve: prevent directory listing - django

I have a /static/ subdirectory in my django application (hosted on appengine) which is used to serve images, .js and .css files (with django.views.static.serve).
I would like to prevent directory listing on that subdirectory, but the .htaccess doesn't seem to work. How can i do that ?

There is a lot of confusion in this question.
.htaccess is a feature of the Apache web server, so naturally it won't work on a site that is not being served by Apache.
django.views.static.serve is a method of serving files that is only for development. It must not be used in a production site - in fact, as the documentation states, it does not even work if DEBUG is False.
App Engine has its own method of serving static assets, via handler paths configured in app.yaml, and this is what you should be using for an App Engine app. This method does not support directory listing anyway.

Related

Can not able to serve media files on cpanel django

I build a website with Django and now hosting it. I used Whitenoise to serve images but only static ones shows up when debug is False. How can I serve media files uploaded by users too? Since it is my first development with Django detailed help would be much appreciated kind folk of the Stack.
I reached my host provider's support and thanks to them I saw it was not that hard. Since I am using a shared host they was conigured serving files defult with CloudLinux. All I have to do is take static and media files on public_html folder. And change the media root for here because I want users uploaded images to get here too. To sum up solution is public_html folder.

Unable to use gatsby website in offline mode

I've built a gatsby website, but when I try to use it offline (by directly loading index.html into my browser), it fails to load the files in the assets folder, and links to other pages fails
running in windows:
after installing gatsby , I did the following:
gatsby new sample
cd sample
gatsby build
then I went to file explorer and opened the sample/dist directory and double clicked on index.html (Chrome is my default browser, but IE behaves the same)
the result is a half-loaded webpage that is missing the style sheets, javascript, images, and links are broken.
For instance, the "about" link on the first page points to "D:/about" vs. ".\about.html".
Is there anyway to make gatsby work to create a truly off-line website?
I've built a gatsby website, but when I try to use it offline (by directly loading index.html into my browser), it fails to load the files in the assets folder, and links to other pages fails
Gatsby will create a React app for you when it is built, and because most React apps use client-side routing, your links won't work with file:// URLs.
After installing the Gatsby CLI and building your site with gatsby build you should run gatsby serve which will serve up index.html with a static file server on your own machine.
See a similar answer about create-react-app here
Try using gatsby serve from the root of your project. Serve spins up a web server to serve your prod build.
Look it up on the Gatsby CLI docs on their site.
Gatsby isn't really set up to do that, unfortunately. It's a site generator, not page generator, and it expects living on a server. The result is that while the files are static, the navigation isn't.
Because I spent some time experimenting, this is what DOESN'T work:
Setting . as pathPrefix in gatsby-config.js. Gatsby lets you set path prefix, which it then prepends to all generated urls. Unfortunately, this prefix always gets "absolutized" somehow. . gets converted to /., for example.
Setting the absolute path of the file on disk as pathPrefix. Same as above - file:///path/to/file doesn't survive the build (results in file:/) and /path/to/file breaks the JavaScript.
Setting the pathPrefix to a bogus value like /NOTAPREFIX and search-replacing it in the generated files. Breaks the JavaScript, again.
Something I haven't tried but might get you somewhere, would be to disable the Single Page App functionality. It's possible, reportedly, (or maybe with this plugin?) but no good step-by-step instructions anywhere.

Media server vs normal server

I am designing an iphone forum application with django running in amazon ec2. Currently I am learning to deploy django using either nginx or apache. I am confused about media server and normal server. A lot of sources say that nginx is good for serving media files or static content, what does that mean? For normal group conversation/forum application, how does apache and nginx differ in performance etc? When is my mobile application serving dynamic content and when is it serving static content?
Googling will find you better results for a comparison between Apache vs Nginx than anyone on this site can give you. It is too broad of a question and can be highly subjective.
Media Files
Media in a django context generally refers to files that have been uploaded by end users. It is common to have a django view that initially uploads the users file, but then any future access to it is served by a traditional web server like nginx.See the docs for more info.
Static Files
Static in a django context refer to images, javascript and css files. While developing your site, the built-in django development server will serve these files for you. However, when moving to production you will want to use a traditional web server like apache to serve these files. See the docs for more details.
Dynamic Content
This would refer to the content (html, json, xml etc.) that is generated by the views that you write within Django.

django serving media files in production (comparing to PHP frameworks)

I'm a django newbie. I've read that all django projects, deployed in production environment, should serve media files (uploads) through web server such as apache. My question is - why is that?
There are lots of PHP frameworks - eg. symfony 1 and 2 - which don't follow the rule. Once you've made your app accessible through a web server, you don't have to change anything depending on the env you deploy. There is just the DOCUMENT_ROOT configured on the web server and somewhere inside this directory lies the upload directory - that's all. You can be sure that no one will access PHP, sql files and so on - thanks to the proper framework architecture and the document root. Why is it different in django?
edit: besides, preparing different code for different environments (e.g. this) is quite a bad approach, since you can't use exactly the same code to deploy a project in different envs (and the code from the link makes sense only for debug env.
Because with PHP your code is served from web server's public directories together with static and media files. So when you request any of these static files web server serves them directly without executing any PHP code along the way.
In Django your code is running separately and all requests are processed by python code in Django. This is inefficient to serve static files, it's more efficient to serve allow a web server like Apache or Nginx to serve them directly without going through any python code.

Does it matter where the Django project exists on the system?

Aside from not deploying a Django project to the web site root directory, is there any specific benefit to running Django projects from one location, e.g. /var/django-projects/**xxxxx-project/ vs. (in a shared hosting environment) running each Django project in a domain folder, e.g. **/vhost/mydomain.com/xxxxx-project?
Doesn't matter -- choose an organization that fits your needs.
I roughly followed this guide when creating a server to handle several Django sites, and I like the folder organization it uses. A couple of benefits:
All Django sites are in a special django user's home directory
There is a domains folder, then a folder for every site that contains the django projects, logs, wsgi files, and other files
VirtualHost containers are each in the own file, keeing httpd.conf manageable.
Realistically it shouldn't matter where you put them so long as you're consistent.
I think the biggest argument one way or another would boil down to file system permissions and where related files will be. If you are allowing development from different users on the projects but want to limit their scope, this is where the split will make more sense.
No except to extent that you mention, ie., that it shouldn't be under DocumentRoot for any site.
You should also ensure that the WSGI script file is not in the same directory as the Django settings file as doing so would generally see you saying to Apache that that directory can be served up by Apache. This may not happen as there will be no Alias directive mapping a URL to that directory, but you have still removed one layer of protection from Apache security.
So, follow the guidelines in:
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
and have the WSGI script file in a directory of its own which has no source code at all under it, or have the WSGI script file in a completely different directory outside of Django project, which again contains only script files of other files that Apache would technically be allowed to serve up.
Basic rule is don't stick source code (except for WSGI script file) in any directory for which:
Allow from all
has been defined by way of Apache configuration.
Of course, above partly assumes you are using mod_wsgi. :-)