Changes between Version 28 and Version 29 of SplitSettings


Ignore:
Timestamp:
08/14/2012 06:52:11 PM (3 years ago)
Author:
wiml
Comment:

My approach: exec and open()

Legend:

Unmodified
Added
Removed
Modified
  • SplitSettings

    v28 v29  
    266266# More development/maching specific settings
    267267}}}
     268
     269== Using exec to incorporate local settings ==
     270
     271I've been using code like this to incorporate local settings:
     272
     273`settings.py`
     274{{{
     275#!python
     276# Non-machine-specific settings live directly in settings.py
     277# Machine-specific settings live in another file, perhaps local_settings.conf
     278
     279exec open('local_settings.conf') in globals()
     280}}}
     281
     282This allows the local settings to both read and modify the main settings' values (and it's simple).
     283
     284As an enhancement, a small amount of privilege separation can be had by making the `local_settings.conf` file unreadable by the uid that runs the web app, opening local_settings.conf in a setuid wrapper, passing its file descriptor to the Django process, and using {{{exec os.fdopen(..., 'r') in globals()}}}. This isn't perfect, since any secrets read from that file are still stored in the Django process, but it does make it harder for someone who has gained access to the user id running the Django app to discover your secrets. (Obviously all of the Python files used by the app must be owned by a user other than the one the app runs as, as well.)
    268285
    269286== Using a list of conf files (Transifex) ==
Back to Top