He leído muchos temas aquí sobre django SECRET_KEY , pero la mayoría de ellos tratan sobre cómo almacenarlo en una variable de entorno en lugar de settings.py , en esta etapa todo está claro. Actualmente lo guardo en .env localmente y en config var en heroku.
Estoy confundido acerca de 2 puntos en conflicto que no puedo combinar.
Se considera una buena práctica mantener en secreto SECRET_KEY . De los documentos:
En lugar de codificar la clave secreta en su módulo de configuración, considere cargarla desde una variable de entorno
Además de eso, github se calienta en el correo electrónico si tiene SECRET_KEY explícito en su código:
GitGuardian ha detectado la siguiente clave secreta de Django expuesta dentro de su cuenta de GitHub.
Quiero permitir que cualquiera pueda ejecutar mi proyecto localmente. Lo tengo en github y la versión implementada en heroku, pero sigue siendo un proyecto de demostración que se usa como parte de la cartera, no como uno serio.
Entonces, si coloco SECRET_KEY en el entorno local, las personas que git clone mi aplicación e intenten ejecutarla, obviamente, no podrán hacerlo ya que no tienen acceso a SECRET_KEY en mi entorno.
¿Cuál es la solución aquí? ¿Debería romper la convención de protección y ponerla explícitamente en settings.py ?
Estoy seguro de que hay varias soluciones que difieren en lo fáciles de usar que son y en lo seguras que son.
Podría usar un valor predeterminado como respaldo para la variable de entorno. También es posible que desee asegurarse de que esto solo funcione si DEBUG está configurado en True , para que nadie use la clave predeterminada en producción.
Yo uso el siguiente fragmento de código:
from warnings import warn from uuid import uuid1 def parse_bool(value): if not value: return False if isinstance(value, str): if value.isdigit(): value = int(value) else: value = value.lower() != 'false' return bool(value) # SECURITY WARNING: don't run with debug turned on in production! DEBUG = parse_bool(os.getenv('DEBUG')) # SECURITY WARNING: keep the secret key used in production secret! if os.getenv('SECRET_KEY'): SECRET_KEY = os.getenv('SECRET_KEY') elif DEBUG: SECRET_KEY = 'secret' else: SECRET_KEY = str(uuid1()) warn('Using random SECRET_KEY. ' 'Should configure it for production.')Las compensaciones son
DEBUG de forma predeterminada, lo que significa una menor posibilidad de implementar en modo DEBUG .SECRET_KEY del entorno cuando está disponible.DEBUG usa SECRET_KEY codificado de forma rígida para que las sesiones se conserven durante el desarrollo.SECRET_KEY cuando no se proporciona SECRET_KEY y no en DEBUG . Esto aún permite ejecutar el código sin la configuración adecuada y codificar una clave de producción y debería ser lo suficientemente seguro ya que las claves son únicas.En resumen, sin configuración, ejecuta la producción con una clave única bastante fuerte con la principal desventaja de verse obligado a volver a iniciar sesión después de cada reinicio.