I have picked up python/django just barely a year. Deployment of django site is still a subject that I have many questions about, though I have successfully manual deployed my site. One of my biggest questions around deployment is what measures can I take to safeguard the source code of my apps, including passwords in django's setting.py, from others, especially when my site runs on a virtual hosting provided by some 3rd party. Call me paranoid but the fact that my source code is running on a third-party server, which someone has the privileges to access anything/anywhere on the server, makes me feel uneasy.
-
1"Call me paranoid" - yes, you're paranoid. – Daniel Roseman Apr 24 '12 at 19:15
-
1@ahmoo The best option is to find a provider you can trust. – Michael Mior Apr 24 '12 at 19:30
-
1I second Daniel and Michael. There's really not a lot you can do. Even if you only deployed the .pyc files, those can be de-compiled. – Brandon Taylor Apr 24 '12 at 19:32
-
Thx guys. Glad to learn that I am really paranoid, and that I am not missing some steps that everyone else is doing on this subject. – tamakisquare Apr 24 '12 at 19:41
4 Answers
If someone has the privileges to access anything/anywhere on the server
you can't do much, because what you can do others can do too, you can try some way of obfuscation but that will not work. Only solution is NOT to use such shared repository.
Edit: options
- Keep working with shared repository if your data is not very sensitive
- Use dedicated hosting from companies like rack-space etc
- Use AWS to run your own instance
- Use google-app-engine server but that may require a DB change
- Run your own server (most secure)

- 85,954
- 40
- 175
- 219
-
What are some of other options? (I don't want to run my own server) – tamakisquare Apr 24 '12 at 19:26
-
Thanks for the additional info. One last follow-up question. What about the plain string passwords in settings.py? Should I be doing something about it? – tamakisquare Apr 24 '12 at 19:36
-
@ahmoo you can not do anything about that, if django can import settings.py or pyc and get password, so can a person – Anurag Uniyal Apr 24 '12 at 19:41
There is almost no scenario where your hosting provider would be interested in your source code. The source code of most websites just isn't worth very much.
If you really feel it is necessary to protect your source code, the best thing to do is serve it from a system that you own and control physically and have exclusive access to.
Failing that, there are a few techniques for obfuscating python, the most straightforward of which is to only push .pyc files and not .py files to your production server. However, this is not standard practice with Django because theft of web site source code by hosting providers is not really an extant problem. I do not know whether or not this technique would work with Django specifically.

- 19,595
- 7
- 57
- 73
-
Ok. How about the passwords in my settings.py? Should I feel comfortable leaving them in plain strings? – tamakisquare Apr 24 '12 at 19:30
-
pyc wouldn't do anything: if django can import settings.py or pyc and get password, so can a person – Anurag Uniyal Apr 24 '12 at 19:41
-
1Yes, .pyc will not protect your passwords. However, neither will anything else. It's just a fact -- your server has to be trusted to access all of the data it needs to access, and someone who has root access to your server will be able to access that data too. Design your security plan around that truth. – Andrew Gorcester Apr 24 '12 at 20:35
While your source code's probably fine where it is, I'd recommend not storing your configuration passwords in plaintext, whether the code file is compiled or not. Rather, have a hash of the appropriate password on the server, have the server generate a hash of the password submitted during login and compare those instead. Standard security practice.
Then again I could just be talking out my rear end since I haven't fussed about with Django yet.

- 11
- 1
-
2That's for storing user passwords, where all you need to do is confirm that whatever password the user submitted is correct. I think the OP is talking about database passwords, which the app needs to be able to submit to the database server. – octern Apr 25 '12 at 04:29
-
Oh, right. Seeing it from that angle makes a lot more sense. In that case, uh... just chmod it conservatively - only have it open enough that your scripts can still reference it and execute. – Temia Eszteri Apr 26 '12 at 17:44
Protecting source code is not that important IMHO. I would just deploy compiled files and not worry too much about it.
Protecting your config (specially passwords) is indeed important. Temia's point is good.

- 1,235
- 8
- 5