Ils auront besoin d'accéder à la base de données. Cet accès se fera par le biais d'un backend de base de données, qui peut être fourni avec Django ou one from a third party. Une chose que j'ai faite sur le site settings.py
de mon site Django est de charger les informations d'accès à la base de données à partir d'un fichier en /etc
. De cette façon, la configuration de l'accès (hôte de base de données, port, nom d'utilisateur, mot de passe) peut être différente pour chaque machine, et les informations sensibles comme le mot de passe ne sont pas dans le référentiel de mon projet. Vous pourriez vouloir restreindre l'accès aux travailleurs de la même manière, en les faisant se connecter avec un nom d'utilisateur différent.
Vous pouvez également transmettre les informations de connexion à la base de données, ou même simplement une clé ou un chemin d'accès à un fichier de configuration, via des variables d'environnement, et le gérer dans settings.py
.
Par exemple, voici comment je tire dans mon fichier de configuration de base de données:
g = {}
dbSetup = {}
execfile(os.environ['DB_CONFIG'], g, dbSetup)
if 'databases' in dbSetup:
DATABASES = dbSetup['databases']
else:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
# ...
}
}
Inutile de dire que vous devez vous assurer que le fichier dans DB_CONFIG
n'est pas accessible à tout utilisateur en plus des admins db et Django lui-même. Le cas par défaut devrait référer Django à la propre base de test d'un développeur. Il peut également y avoir une meilleure solution en utilisant le module ast
au lieu de execfile
, mais je ne l'ai pas encore étudié.
Une autre chose que je fais est d'utiliser des utilisateurs séparés pour les tâches d'administration DB par rapport à tout le reste. Dans mon manage.py
, j'ai ajouté le préambule suivant:
# Find a database configuration, if there is one, and set it in the environment.
adminDBConfFile = '/etc/django/db_admin.py'
dbConfFile = '/etc/django/db_regular.py'
import sys
import os
def goodFile(path):
return os.path.isfile(path) and os.access(path, os.R_OK)
if len(sys.argv) >= 2 and sys.argv[1] in ["syncdb", "dbshell", "migrate"] \
and goodFile(adminDBConfFile):
os.environ['DB_CONFIG'] = adminDBConfFile
elif goodFile(dbConfFile):
os.environ['DB_CONFIG'] = dbConfFile
Lorsque la config dans /etc/django/db_regular.py
est pour un utilisateur avec un accès uniquement à la base de données Django avec SELECT, INSERT, UPDATE et DELETE et /etc/django/db_admin.py
est pour un utilisateur ces autorisations plus CREATE, DROP, INDEX, ALTER et LOCK TABLES. (La commande migrate
est de South.) Cela me protège du code de Django avec mon schéma lors de l'exécution, et limite les dommages qu'une attaque par injection SQL peut causer (bien que vous devriez toujours vérifier et filtrer toutes les entrées utilisateur).
Ce n'est pas une solution à votre problème exact, mais cela peut vous donner des idées pour améliorer la configuration de l'accès à la base de données de Django à vos fins.
Merci! Je pense que c'est un bon moyen de s'assurer que ma connexion à la base de données est entre de bonnes mains. – dotmoo
Vous pouvez également stocker votre paramètre 'SECRET_KEY' en dehors du fichier' settings.py' d'une manière similaire. –