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.


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.
>> 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+unsubscr...@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.


Reply via email to