On Tue, Mar 22, 2011 at 5:17 PM, Carl Meyer wrote:
> Interesting. I would have assumed that the reason is so that code in
> site_settings.py has access to the previously defined values in the main
> settings.py, and can actually modify them (i.e. append to
> MIDDLEWARE_CLASSES or whatnot). With an
I've used the execfile approach in my settings.py like so:
# Include any local settings that override the defaults.
try:
execfile('local_settings.py')
# Hack so that the autoreload will detect changes to local_settings.py.
class dummymodule(str):
__file__ = property(lambda self
On 03/22/2011 07:05 PM, Ian Kelly wrote:
> On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt
> wrote:
>> Why not just do an import for your custom settings?
>>
>> try:
>>from site_settings import *
>> except ImportError:
>>pass
>
> No particularly compelling reason that I know of,
That's just interesting. I've never seen the use of `execfile()` before. We use
a devsettings.py and use it to override an individual server or local settings,
and then on the live/deployed server, no devsettings.py is even included. Hence
the try...except wrapped around it. It's a nice little p
On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt
wrote:
> Why not just do an import for your custom settings?
>
> try:
> from site_settings import *
> except ImportError:
> pass
No particularly compelling reason that I know of, the import machinery
is just unnecessary in this case. T
Why not just do an import for your custom settings?
try:
from site_settings import *
except ImportError:
pass
On Mar 22, 2011, at 5:51 PM, Ian Kelly wrote:
> On Tue, Mar 22, 2011 at 6:44 AM, Kristaps Kūlis
> wrote:
>> I personally would greatly appreciate update in docs to sho
On Tue, Mar 22, 2011 at 6:44 AM, Kristaps Kūlis
wrote:
> 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 a
I would be in support of a manage.py command to change the secret key,
just as a convenience. I'd be happy to implement it.
Matthew Roy said:
> 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 traffi
On 22/03/11 12:44, Kristaps Kūlis wrote:
> 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,
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
produc
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
fr
On 21 March 2011 18:07, Matt Harasymczuk 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
settings.py already has a warning:
# Make this unique, and don't share it with anybo
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 wrote:
> "real" config should not be in version control
What we use is a settings.cfg, which is an ini file for global
configurations. Database settings, etc. We need to share these settings
across different languages and parts of our application.
You can set up your ini file as such:
[secret]
key=abcdefghijklmnopqrstuvwxyz0123456789
ini files are
"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 cred
I had an idea.
>From time to time I find on the Internet a django app source code with
secret_key shown.
how about creating an secret.key file next to settings.py in main
project module, which should be added by developer
to .gitignore, .hgignore or equivalent
in settings we read key from file to
16 matches
Mail list logo
