Re: Django split setting and environment variables

On 22/03/2013 7:58am, Alan Johnson wrote:
> I think hardcoding local machine development passwords is fine, but it's
> still better to store the production passwords in a key-value file that
> stays out of source control and is permissioned such that only
> authorized developers can directly access the server or the credential
> file. Of course any developer with full access to the production servers
> also has the password, but at that point, so what? Exactly how to set it
> up depends on the hosting setup.

I agree. I like to use a callable to fetch the credentials from a
non-versioned directory. I have a simple text file with a separate line
for each item. All settings.py needs to do is something like this ...

dbhost = getcreds('db.host')
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': PROJECT,
'USER': dbhost[0],
'PASSWORD': dbhost[1],
'HOST': dbhost[2],
'PORT': dbhost[3],

... where

getcreds(pth='/somewhere/for/this/project', credfile)

This prevents accidentally broadcasting sensitive info when sharing
settings.py or dropping it on the list when asking for help.

>
>
> On Thursday, March 21, 2013 2:08:39 PM UTC-4, ke1g wrote:
>
> Are you doing this for password security? If so, note that, while
> not quite as easy as scraping command line argument, your
> environment is avilable via /dev/mem, and is trivially available to
> any Trojan that an attacker can convince this shell or any of its
> children (such as Django or any manage.py app) to execute.
>
> Note, too, that, unless you are going to type this each time that
> you start the server, you have to put it in a file somewhere, be it
> .bashrc, .bash_profile, or some script file that you use to start
> django and the management apps. And if it's in a file, then it is
> at least as good to have it in settings.py .
>
> And if you are willing to type a password, either let settings.py
> read it to use to decrypt a file with the full credentials, or use
> one of the password manager apps that settings.py can talk to over
> the D-bus (linux) or equivalent.
>
> But note that security is hard, and most "simple" home grown
> solutions, very likely including my suggestions above, end up by
> reducing security.
>
> On Thu, Mar 21, 2013 at 10:42 AM, demet8 <dem...@gmail.com
> <javascript:>> wrote:
>
> I have a common.py, dev.py, and prod.py for my Django settings
> files. All files inherit from common.py. I want to keep my
> database passwords, database URL, etc stored as environment
> variables. I have researched the topic but I am not sure If I
> have a clear understanding of it. I am hoping I can get a more
> comprehensive answer via this forum. This is what I have thus far:
>
>
> *In your bash shell type:*
>
> export SOMEAPP_DB_USER='someapp'
> export SOMEAPP_DB_PASSWORD='1234'
>
> *In my Django settings file type*:
>
> DATABASE_USER = os.environ.get("SOMEAPP_DB___USER", ")
> DATABASE_PASSWORD = os.environ.get("SOMEAPP_DB___PASSWORD", ")
>
> So are my passwords stored in just a terminal session? or are
> they being stored in something like my bash_profile?
>
>
> A means whereby you have to type them to a shell is to type them as
> above each time, then run python manage.py runserver, or maybe
> better, exec python manage.py runserver (the shell that knows the
> password goes away as a process in this case, so maybe you firist
> start a secondary bash by typing "bash" at your shell prompt. Note
> that this DOES NOT help you in deployment, behind Apache/mod_wsgi,
> for example, since it would be the shell that started Apache that
> would have to have these environment variables. You can add
> environment variables in the Apache configuration, by the way, but
> that's just another file that knows your password.
>
>
> Thanks.
>
> --
> You received this message because you are subscribed to the
> Google Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to django-users...@googlegroups.com <javascript:>.
> To post to this group, send email to django...@googlegroups.com
> <javascript:>.
> Visit this group at
> http://groups.google.com/group/django-users?hl=en
> <http://groups.google.com/group/django-users?hl=en>.
> For more options, visit https://groups.google.com/groups/opt_out
> <https://groups.google.com/groups/opt_out>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users+unsubscribe@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.