sorry the code you need to write with my solution in your settings file
would be
class Settings(object):
@property
def SECRET_KEY(self):
if self.DEBUG:
return "abcd"
return "12345"
On Sunday, January 25, 2015 at 2:38:29 PM UTC+1, Riccardo Di Virgilio wrote:
>
> What you can try to do without modifying django code is to use custom
> settings class, which is a documented feature.
>
>
> https://docs.djangoproject.com/en/1.7/topics/settings/#custom-default-settings
>
> I'm doing that for my application, using a class that is using @property
> decorator to build dynamic settings.
>
> I'm attaching the code that I'm currently using to use custom settings,
> this code replace the built in
> django.core.management.execute_from_command_line
>
> What I'm doing is to create several settings that are shared across my
> django applications, and they are classes that can ineherit attributes,
> instead of being just modules.
>
> the nice thing about this code is that you can create settings from a
> dict, from a module or from a class.
>
> Take a look, maybe this can be a solution for your problem.
>
>
>
>
>
>
> On Saturday, January 24, 2015 at 4:57:23 PM UTC+1, Marc Tamlyn wrote:
>>
>> I'm not sure what the benefit here would be - the settings are evaluated
>> at start up time, not on every request and the server would need to be
>> restarted for it to change.
>>
>> A patch to db.connections which allows the username and password to be
>> looked up on each new connection might be interesting, although I'd be
>> concerned that for any reasonably high traffic site this would be happening
>> a *lot*, normally during a user request. Something like caching it and then
>> clearing the cache when it changes upstream would be more appropriate.
>>
>> Marc
>>
>> On 24 January 2015 at 03:06, 'Andres Mejia' via Django developers
>> (Contributions to Django itself) <[email protected]> wrote:
>>
>>> Hello Django devs,
>>>
>>> I would like to see if Django can support setting the SECRET_KEY and
>>> database creds as callables. Let me explain my situation.
>>>
>>> Here at Amazon, we use a system to store and fetch secrets such as a
>>> Django SECRET_KEY and database creds. There's a Python component to this
>>> system which works something like this.
>>>
>>> SECRET_KEY = get_creds(secret_key_id, type='privatekey')
>>> . . .
>>> DATABASES = {
>>> 'default' = {
>>> . . .
>>> 'USER': get_creds(database_creds_id, type='username'),
>>> 'PASSWORD': get_creds(database_creds_id, type='password'),
>>> },
>>> . . .
>>> }
>>>
>>> Secrets are rotated on a regular schedule or as needed. Often times the
>>> secrets are rotated without advance notice and therefore our various Django
>>> powered sites go down (because they can't connect to the database) until
>>> the web servers are restarted. We would prefer it if our web services did
>>> not have to be restarted.
>>>
>>> I was going to propose a patch which modifies the force_text and
>>> force_bytes methods in django.utils.encoding. The modifications basically
>>> involves adding an if statement.
>>>
>>> if hasattr(s, '__call__'):
>>> return s()
>>>
>>> This would support setting the SECRET_KEY and database creds as
>>> callables with no arguments. Example.
>>>
>>> SECRET_KEY = lambda: get_creds(secret_key_id, type='privatekey')
>>> . . .
>>> DATABASES = {
>>> 'default' = {
>>> . . .
>>> 'USER': lambda: get_creds(database_creds_id, type='username'),
>>> 'PASSWORD': lambda: get_creds(database_creds_id,
>>> type='password'),
>>> },
>>> . . .
>>> }
>>>
>>> My question is, should I submit a patch or might there be some other way
>>> to address my use case? Also, I'm aware of the various examples which call
>>> for storing secrets in a separate file. We cannot store secrets on the
>>> local disk (this is partly the reason for the use of the system I
>>> explained).
>>>
>>> --
>>> Andres
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/django-developers/54C30C4D.4030302%40amazon.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/0c6a625d-2a36-4337-9cda-2a0dd14f16b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
