I am using Django to develop an API using an algorithm I wrote.
When someone requests a url, my urls.py calls a function in views.py which serves
page that returns a JSON string.
If my algorithm is in my views.py file, or in another file on my server, would it be possible for a user to view the contents of this file, and then see my algorithm?
In other words, when using Django, which files will never be served to a user, and which files will be?
Is there any way I can stop someone from viewing my algorithm if it's in a .py file? Other than Chmodding the file or encrypting the code?
Thank you for your time.
Django only serves the responses that you explicitly create and return from your views. There is no general ability to request files from it.
Make sure your source code isn't in a directory that your web server is configured to serve from, and make sure your settings.py value for DEBUG is False, and you should be fine. Oh, and just in case - don't try to use the Django development server in production.
As long as nobody has shell access to your server, people will never see more than the actual HTML output of your page. .py files are not shown to the user that has requested an url in the browser.
Related
I'm using gunicorn and nginx to serve a flask application, my website has a blogging feature where users can write blogs, once they do, their input is saved as an html file (I use tinyMCE to generate it) and a flask view is added to a views.py file. Now, in deployment, I just used
use_reloader=True
This ensured that every time a new file was added, it was detected, now in production, I don't know how to implement it, gunicorn has --reload option but the docs say that it's only for development. Can someone please provide an insight on how to implement this feature? Thanks!
You don't need a new view for every html file. You could use a generic view that renders the appropriate html according to the url requested.
Django currently has a complete system for routing urls.
But I have a very specific situation where I am using django but actually need to use urls like in classic PHP language.
For example:
The url - localhost/reader/theeffort should take me to a folder called theeffort where I have my files index.html, 1.html, 2.html, 3.html
and so on!
Now all these files should be accessible by localhost/reader/theeffort/*.html and not by Django's default url system. Is this possible to achieve that? If yes, how?
This isn't a thing you would do with Django's URLs. If you just want to serve HTML files within a folder, they are static files; they should therefore be served by the web server itself, eg Apache. You just need to configure an alias in the Apache conf to point to the folder where the static files are.
I've got a Django app running on localhost:80, and another app running on localhost:41984. Now, in the app, I'm trying to hook things up so that hitting localhost/view/41984 redirects to localhost:41984, without changing the URL in the browser: effectively, URL masking of sorts.
Could someone give me some pointers on achieving this? Django's HttpResponseRedirect does the redirection, but the URL changes too, which isn't what I want. I read somewhere that people do this with .htaccess, but I'm not planning on using Apache.
Thanks!
The best option should be, to run both app in the same server. Just add one to the INSTALLED_APPS list.
Then, you can do:
return redirect('some-view-name', foo='bar')
The view name is the one you define in the urls.py file:
url(r'^enter/$', 'yourApp.views.viewName', name='some-view-name'),
For more info https://docs.djangoproject.com/en/dev/topics/http/shortcuts/#redirect
If you need to run booth app in differents servers... I would say that you need a REAL web server, apache, ngix... what you want, but no ./manage.py runserver
I am working on a django project that provides an API to generate thumbnails of images, and the basic logic is like the following:
when the source image URL comes for the first time, the django would do some sort of image manipulation, and return the thumbnail image
when the same image URL comes again, django would simply serve the previous thumbnail image (stored as static media) again.
basically, case 2 happened much often than case 1. Now I used django to serve the images all the time, which I believe is a bad practice.
I wonder if it's possible to do a better way of image serving for case 2? For example, is there some sort of way to ask django to send proxy requests to apache and ask apache to serve the file?
I know I could use HTTP redirect to do that, but that seems to generate too much redirect requests on the client side (one HTML page would contain a lot of links to this API).
thx.
The simplest solution of the top of my head would be to use an Apache rewrite rule with a condition.
RewriteCond %(REQUEST_URI) ^media
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule #Some rewrite rule to redirect from '/media/filename' to '/image_generator/filename'
This basically just checks to see whether the file exists in the media directory, and if it doesn't it sends the user to the image generator, which can then generate and save the file to /media where it can be found for the next request.
NB: I've never actually tried this sort of redirection with Django, so it may need some measure of tweaking..
For example, is there some sort of way to ask django to send proxy requests to apache and ask apache to serve the file?
You have that exactly backwards.
Read the Django deployment guide. https://docs.djangoproject.com/en/1.3/howto/deployment/modwsgi/#serving-files
Apache should be serving all static files (images, for example) all the time. Always.
Django should never, ever serve an image file (or a .css or .js or anything other than .html).
See later part of this section in documentation:
http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#The_Apache_Alias_Directive
Using Alias/AddHandler/mod_rewrite allows Django to overlay static files in filesystem. In other words, static files take precedence.
When localising Django application the makemessages command simply parses all the TXT, HTML and PY files and generates PO files for them but when localising JS files, you need to run the djangojs command. I haven't delved into the Django source to figure out why this done differently. Could someone explain?
I've read that in production environments, Apache is used to serve the application files while a simple proxy like Nginx is used to serve static files as this greatly reduces the load on the application server. With this scenario, I guess it works like this: when rendering a template, Django checks the requested locale, loads the appropriate localisation file and serves the template but JS on the other hand being served as static media doesn't get parsed by Django. Is this it?
(Its my first foray in to the world of localisation with Django and I'm packed full of question, many of who's answers I can't seem to find and therefore this post.)
Thanks
The reason why it's handled differently is in the docs.
Adding translations to JavaScript poses some problems:
JavaScript code doesn't have access to a gettext implementation.
JavaScript code doesn't have access to .po or .mo files; they need to be delivered by the server.
The translation catalogs for JavaScript should be kept as small as possible.
So essentially, the internal Python translation is done on the server. But for JS, there's another file served by the server, which contains all the required translations for user's language. And the translation is done on the user's side. So as you can see, it's a completely different strategy. Django helps by adding similar interface for JS files, even though they're handled in a completely different way.
I guess it works like this: when rendering a template, Django checks
the requested locale, loads the appropriate localisation file and
serves the template but JS on the other hand being served as static
media doesn't get parsed by Django. Is this it?
You are right in the first part, about handling templates. Handling JS works as I've explained above.
Note that Django JS translation mechanism, doesn't treat JS translations as static files. It uses a Django view to generate the JS file everytime (javascript_catalog mentioned in the docs linked in the first line).
That is one of the problems I've encountered. Such files don't need to be generated on every request. There are some projects that actually let you pack those JS translations as static files and enable you to cache them properly (like django-mediagenerator).