Задать вопрос

Тел: +7 965 3737 888





Keep settings.py in version control safely

Here is a trivial way to keep your Django project in shared version control or in a public repository without exposing settings that could have security implications, and without needing to modify settings.py for your local test or production environments on checkout.

This is also a way to separate development settings from production settings, or to deploy the same code on multiple servers while only changing one site-specific "dotfile."

Вопрос полезен? Да0/Нет0

Ответы (3):

Ответ полезен? Да0/Нет0

jeffwheeler, that's a bogus login, password, and key. They shoot people for using passwords like that. I'll change my code so it's more obvious.

robhudson, yes, it will throw an error if the file isn't found. You could wrap it in a try/except, but then you'll just get an error when DATABASE_ENGINE and friends are empty strings.

This is the simplest of mechanisms, and I claim nothing lofty for it. It's my response to several Django snippets (and some projects in public version control) that work so hard to separate production from DEBUG settings, but in the process create lots of conditional code and still leave in potentially compromising settings. "Check out of svn, then don't forget to modify the settings.py" is a recipe for disaster that this at least fixes.

Ответ полезен? Да0/Нет0

What happens when you load the project on a production machine with no file matching "~/.django-mysite-settings"? Does the execfile throw an error?

Ответ полезен? Да0/Нет0

You might want to remove your username and password from the .django-mysite-settings file, if that is in fact your real password. Looks like it.