I personally would greatly appreciate update in docs to show "best
way" to handle per enviroment settings / sensitive settings, as now
there is many ways :)
Consider when one has his local development enviroment with locmem
cache and sqlite3 db, and staging server with MySQL / memcache and
production cluster with MySQL (different credentials) and memcache
cluster. In settings.py most deployment specific stuff is left blank
and on deployment {staging/production}_settings.py is created with
from settings import * and then overriding per env settings :).
Actually it took me far too much googling to find "how" and "what" to
do, at least I believe that such stuff should be put in docs to make
django more sysadmin friendly.
Kristaps Kūlis
On Mon, Mar 21, 2011 at 8:01 PM, Matthew Roy <matt...@royhousehold.net> wrote:
> I don't think settings.py needs to be any more complicated by default.
> Personally, I do keep my db passwords in the settings file under version
> control. It seems pretty clear that it shouldn't be under public revision
> control. I also do (nearly) exactly what you describe to load the secret key
> from the filesystem.
> For the base installation the compromise of the settings.py actually isn't
> all that bad. MySQL defaults to listening only on localhost and the database
> user is mapped to localhost if you follow the tutorial. Memcache is a
> non-default addition, and IIRC also defaults to localhost. If I understand
> how it works the compromise of the SECRET_KEY alone doesn't put you in
> serious hot water unless the attacker can also intercept traffic. This leads
> me to the conclusion that a novice users really doesn't need to worry about
> heavily securing the values in settings.py until the are ready to grow their
> setup.
> That said, an automated tool to write a secret key to the file system and
> update settings.py to load it could make sense as a way to help users bridge
> the gap between the simple and moderately complex deployments.
>
> Matthew
>
>
> On Mon, Mar 21, 2011 at 13:07, Matt Harasymczuk <m...@harasymczuk.pl> wrote:
>>
>> Thats right,
>> there should be a secret_settings.py file with db credentials and
>> secret_key
>> also a warning that it should not be added to version control
>>
>>
>> --
>> Matt Harasymczuk
>> http://www.matt.harasymczuk.pl
>>
>> On Mar 21, 5:07 pm, Kristaps Kūlis <kristaps.ku...@gmail.com> wrote:
>> > "real" config should not be in version control system, only reference
>> > config should be stored in version control.
>> >
>> > Consider database credentials - they should not be publicly available
>> > / downloadable from internet and they fall in same category -
>> > sensitive information in settings.py .
>> > Memcache credentials - in many cases memcache is unprotected .
>> >
>> > I think docs should be updated to reflect sensitive settings.py
>> > variables, which are confidential and provide "best practices" way
>> > ({local|secret}_settings.py ?) for deployment :). Perhaps manage.py
>> > command to generate adequate strenght / randomness secret would be
>> > beneficial .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
