Domanda Distribuire progetti Django con unici SECRET_KEY


Ho un progetto Django che vorrei distribuire su un repository pubblico come bitbucket o github. Mi piacerebbe che fosse il più facile da installare possibile, quindi includo il progetto completo, non solo le app collegabili. Ciò significa che il settings.py anche il file sarà incluso.

Come posso evitare il problema di settings.SECRET_KEY essere uguale per ogni installazione?

È l'unico semplice soluzione per consentire all'utente di modificare manualmente settings.py?

Devo memorizzare la chiave nel database predefinito e avere settings.py inizializzarlo se non esiste? Ciò risolverebbe il problema, ma mi chiedo se esiste già un modo standard per farlo.

Grazie!


44
2018-01-12 02:05


origine


risposte:


Lo farei in questo modo:

Avere la chiave segreta in un file separato "secret_key.py". Questo file non esiste per un'installazione pristine. Nel tuo settings.py include qualcosa come:

try:
    from .secret_key import SECRET_KEY
except ImportError:
    SETTINGS_DIR = os.path.abspath(os.path.dirname(__file__))
    generate_secret_key(os.path.join(SETTINGS_DIR, 'secret_key.py'))
    from .secret_key import SECRET_KEY

La funzione generate_secret_key(filename) che scriverai genera un file chiamato filename (che, come lo chiameremo, sarà secret_key.py nella stessa dir di settings.py) con i contenuti:

SECRET_KEY = '....random string....'

Dove stringa casuale è la chiave generata in base a un numero casuale.

Per la generazione delle chiavi puoi usare il suggerimento di Umang https://stackoverflow.com/a/16630719/166761.


35
2018-01-12 21:13



Per aggiungere a cosa Carles Barrobés detto, è possibile generare una nuova chiave usando il metodo che Django usa in startproject:

from django.utils.crypto import get_random_string

chars = 'abcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*(-_=+)'
get_random_string(50, chars)

63
2018-05-19 01:49



In generale, puoi dividere la configurazione di Django in cose che sono specifiche dell'app e cose specifiche del server. Questo rientra in quest'ultima categoria.

Esistono diversi modi per affrontare il problema della configurazione specifica del server, ne viene discusso di più questa domanda.

Per questa particolare istanza, utilizzando l'approccio che ho delineato nella mia risposta all'altra domanda, inserisco un segnaposto settings_local.py.sample per la distribuzione e durante l'installazione, lo coperei su settings_local.py e modificare per soddisfare.


5
2018-01-12 02:16



Vorrei risolvere il problema in questo modo:

  • Fornire una chiave segreta fittizia come: I_AM_A_DUMMY_KEY_CHANGE_ME
  • Crea un comando di gestione per generarne uno nuovo: ./manage.py gen_secret_key
  • Nella documentazione, FORTEMENTE consiglia agli utenti di eseguire il comando il prima possibile

2
2018-05-19 00:59



Nel mio codice ho tre livelli di file di impostazioni ispirati a Two Scoops of Django, quindi uno di mezzo va così, dove BASE_PRIVATE_DIR è impostato nel modello base. Nel mio caso questo è dalla directory django ../../mysite_private ma da qualche parte nei normali file sotto l'applicazione git .:

from .base import *

ALLOWED_HOSTS = ['staging.django.site'] 
#Allow local override which is per deployment instance.  There should probably then be
#  an instance git for version control of the production data
try:
    import sys
    private_path = BASE_PRIVATE_DIR.child('production')
    sys.path.append(private_path)
    from private_settings import *
except ImportError:
    print(" No production overide private_settings.py found.  This is probably an error  = {}".format(private_path))
    # If it doesnt' exist that is fine and just use system and environment defaults

1
2018-06-11 20:20



Se crei un nuovo progetto usando il modello, come django-admin.py startproject --template=path_to_template project_name appena messo {{ secret_key }} nel file delle impostazioni del modello di progetto (ad esempio settings.py) SECRET_KEY = '{{ secret_key }}' e Django lo genererà per te.


0
2018-06-21 09:32



In questa soluzione io uso django-dotenv, che è una delle dipendenze del mio progetto, come elencato in requirements.txt piace django-dotenv==1.4.1. Il vantaggio di questo approccio è che hai un altro .env file per ogni ambiente in cui è installata l'applicazione.

Crea il file utils.py nella stessa directory di settings.py con il seguente contenuto:

from django.utils.crypto import get_random_string

def generate_secret_key(env_file_name):
    env_file = open(env_file_name, "w+")
    chars = 'abcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*(-_=+)'
    generated_secret_key = get_random_string(50, chars)
    env_file.write("SECRET_KEY = '{}'\n".format(generated_secret_key))
    env_file.close()

Quindi modificare il settings.py file come segue:

import dotenv
from [project-folder-name] import utils
...
try:
    SECRET_KEY = os.environ['SECRET_KEY']
except KeyError:
    path_env = os.path.join(BASE_DIR, '.env')
    utils.generate_secret_key(path_env)
    dotenv.read_dotenv(path_env)
    SECRET_KEY = os.environ['SECRET_KEY']

Per coloro che non usano django-dotenv, tutto ciò che devi fare per aggiungerlo come dipendenza e cambiare il manage.py per caricarlo all'avvio:

import dotenv

if __name__ == "__main__":
    dotenv.read_dotenv()

0
2018-03-19 12:01