Django కాన్ఫిగరేషన్ settings.pyలో ఉంటుంది, కానీ నిజమైన అనువర్తనాలకు ప్రతి వాతావరణానికి భిన్నమైన సెట్టింగ్లు (డెవలपమెంట్, స్టేజింగ్, ప్రోడక్షన్) అవసరం మరియు సీక్రెట్లను కోడ్ నుండి దూరంగా ఉంచాలి. దీన్ని సరిగ్గా నిర్వహించడం అనేది ఒక కార్యాభిహిత ఆవశ్యకత మరియు సsecurity అవసరం రెండూ.
DEBUG =
SECRET_KEY =
DATABASES = {: {: }}
హార్డ్కోడ్ చేసిన విలువలు వాతావరణాలను కలిపి ఉంచుతాయి మరియు — క్రిటికల్గా — సీక్రెట్లు (SECRET_KEY, డేటాబేస్ పాస్వర్డ్లు, API కీలు) సంస్కరణ నియంత్రణకు కమిట్ చేస్తాయి, ఇది తీవ్రమైన సecurity ఉల్లంఘన.
import os
from pathlib import Path
SECRET_KEY = os.environ["DJANGO_SECRET_KEY"] # from the environment, NOT code
DEBUG = os.environ.get("DJANGO_DEBUG", "False") == "True"
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "").split(",")
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"NAME": os.environ["DB_NAME"],
"PASSWORD": os.environ["DB_PASSWORD"], # injected per environment
}
}
# tools like django-environ / python-decouple make this cleaner (+ .env file support)
కాన్ఫిగరేషన్ను (ముఖ్యంగా సీక్రెట్లను) పరిసర వేరియబుల్ల నుండి చదవడం దీన్ని కోడ్ నుండి దూరంగా ఉంచుతుంది — అదే కోడ్బేస్ విభిన్న ఇంజెక్ట్ చేసిన విలువలతో (twelve-factor విధానం) ఏదైనా వాతావరణంలో నడుస్తుంది.
settings/
base.py # shared settings (apps, middleware, templates)
development.py # from base import *; DEBUG=True, local DB, debug toolbar
production.py # from base import *; DEBUG=False, security hardening, real DB
test.py # test-specific settings
# production.py
from .base import *
DEBUG = False
ALLOWED_HOSTS = ["example.com"]
SECURE_SSL_REDIRECT = True # production-only security settings
# select via: DJANGO_SETTINGS_MODULE=config.settings.production
సెట్టింగ్లను భాగస్వామ్య base.py మరియు ప్రతి-వాతావరణ ఫైల్లుగా విభజించడం (DJANGO_SETTINGS_MODULE ద్వారా ఎంపిక చేసిన) సాధారణ సెట్టింగ్లను పంచుకోవడం సాధారణ సెట్టింగ్లను శుద్ధంగా వేరు చేస్తుంది.
DEBUG = False # ❗ NEVER True in production — leaks sensitive error info
ALLOWED_HOSTS = ["example.com"] # required when DEBUG=False
SECRET_KEY = os.environ[...] # strong, secret, from the environment
# + SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, HSTS, etc. for hardening
✓ NEVER commit secrets — use env vars / a secret manager; gitignore .env
✓ DEBUG=False in production (DEBUG=True leaks tracebacks, settings → security risk)
✓ Commit a .env.example documenting required variables (no real values)
విభిన్న వాతావరణాలలో సెట్టింగ్లను నిర్వహించడం ఏదైనా నిజమైన Django అనువర్తనం కోసం కార్యాభిహిత ఆవశ్యకత మరియు critical security ప్రయోగం రెండూ.
అనువర్తనాలు వాతావరణాలలో భిన్నంగా ప్రవర్తించాలి — డెవలపమెంట్కు DEBUG=True మరియు స편편な స్థానిక సెట్టింగ్లు అవసరం, ప్రోడక్షన్కు DEBUG=False, security గట్టిబిడిగలు, నిజమైన డేటాబేస్లు, మరియు సరైన హోస్ట్లు అవసరం — మరియు ఒకే హార్డ్కోడ్ చేసిన settings.py ఇవన్నీకు సేవ చేయలేము.
ఎక్కువ ముఖ్యమైనది, ఇది major security కంటెంట్: సీక్రెట్లు (SECRET_KEY, డేటాబేస్ పాస్వర్డ్లు, API కీలు) హార్డ్కోడ్ చేయడం వాటిని సంస్కరణ నియంత్రణకు కమిట్ చేస్తుంది, అత్యంత సాధారణ మరియు తీవ్రమైన security ఉల్లంఘనలలో ఒకటి (repo యాక్సెస్ ఉన్న ఎవరైనా, లేదా ప్రజా repoలో, మీ అనువర్తనం మరియు డేటాకు కీలు పొందుతారు).
సమాధానాలను అర్థం చేసుకోవడం — కాన్ఫిగరేషన్ మరియు సీక్రెట్లను పరిసర వేరియబుల్ల నుండి చదవడం (వాటిని కోడ్ నుండి దూరంగా ఉంచుతుంది, twelve-factor విధానం, తరచుగా django-environ మరియు gitignored .env ఫైల్ల వంటి సాధనాలతో) మరియు సెట్టింగ్లను విభజించడం భాగస్వామ్య బేస్ మరియు ప్రతి-వాతావరణ ఫైల్లుగా — Django సురక్షితంగా మరియు సరిగ్గా అమలు చేయడానికి అవసరం.
critical production సెట్టింగ్లను (ముఖ్యంగా DEBUG ఉత్పత్తిలో False కానీ తప్పక ఉండాలి, ఎందుకంటే DEBUG=True tracebacks, మూల మార్గాలు, మరియు సెట్టింగ్లను దాడిచేసేవారికి లీక్ చేస్తుంది, మరియు ALLOWED_HOSTS మరియు security గట్టిబిడిగలు) తెలుసుకోవడం నన-ఎలాంటిది ఉత్పత్తి జ్ఞానం.
సెట్టింగ్ల నిర్వహణను సరిగ్గా పొందడం — పరిసరాలలో సీక్రెట్లు, వాతావరణానికి సరిపోయే కాన్ఫిగరేషన్, సురక్షిత ఉత్పత్తి డిఫాల్ట్లు — Django అనువర్తనాలను నిపుణంగా నడపడానికి మరియు లీక్ చేసిన సీక్రెట్లు లేదా misconfigured ఉత్పత్తి పరిసరాల నుండి సంభవించే తీవ్రమైన vulnerabilities నుండి తప్పించడానికి ప్రాథమికమైనది, ఏదైనా నిజమైన అమలు కోసం ఇది ముఖ్యమైన, ఆచరణాత్మక-కీలుమైన జ్ఞానం చేస్తుంది.