Cum gestionezi setările în diferite medii?

Question

IT Interview Practice · Accepted Answer

Configurația Django trăiește în `settings.py`, dar aplicațiile reale au nevoie de **setări diferite per mediu** (dezvoltare, staging, producție) și trebuie să mențină **secretele în afara codului**. Gestionarea corectă a acestora este atât o necesitate operațională, cât și o cerință de securitate.

## Problema cu un singur settings.py

```python
# ❌ hardcoded, environment-mixed, and INSECURE settings
DEBUG = True                                    # must be False in production!
SECRET_KEY = "hardcoded-secret-in-code"          # ❌ secret committed to git
DATABASES = {"default": {"PASSWORD": "prod-pw"}} # ❌ production password in code
```

Hardcodificarea valorilor amestecă mediile și — în mod critic — angajează secrete (SECRET_KEY, parole de bază de date, chei API) în controlul versiunilor, o breșă de securitate serioasă.

## Soluția 1: citi configurația din variabilele de mediu

```python
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)
```

Citirea configurației (în special a secretelor) din **variabilele de mediu** o ține în afara codului — aceeași bază de cod rulează în orice mediu cu valori injectate diferite (abordarea twelve-factor).

## Soluția 2: împărți fișierele de setări per mediu

```text
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
```

```python
# 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
```

Împărțirea setărilor într-un fișier `base.py` partajat plus fișiere per mediu (selectate prin `DJANGO_SETTINGS_MODULE`) separă curat configurația specifică mediului în timp ce partajează setări comune.

## Setări critice pentru producție

```python
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
```

```text
✓ 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)
```

## De ce are importanță

Gestionarea setărilor în diferite medii este atât o **necesitate operațională**, cât și o **practică critică de securitate** pentru orice aplicație Django reală.

Aplicațiile trebuie să se comporte diferit în diferite medii — dezvoltarea are nevoie de `DEBUG=True` și setări locale convenabile, în timp ce producția necesită `DEBUG=False`, consolidare de securitate, baze de date reale și gazde corespunzătoare — și un singur `settings.py` hardcodat nu poate servi toate acestea.

Mai important, aceasta este o **problemă majoră de securitate**: hardcodificarea secretelor (SECRET_KEY, parole de bază de date, chei API) le angajează în controlul versiunilor, una dintre cele mai frecvente și grave breșe de securitate (oricine cu acces la repo, sau într-un repo public, obține cheile aplicației și datelor tale).

Înțelegerea soluțiilor — citirea configurației și secretelor din **variabilele de mediu** (ținând-le în afara codului, abordarea twelve-factor, adesea cu instrumente precum django-environ și fișiere `.env` ignorate de git) și **împărțirea setărilor** într-o bază partajată plus fișiere per mediu — este esențială pentru implementarea Django în siguranță și corect.

Cunoașterea **setărilor critice pentru producție** (în special că `DEBUG` trebuie să fie `False` în producție, deoarece `DEBUG=True` scapă urme ale stivei, căi ale surselor și setări atacatorilor, plus `ALLOWED_HOSTS` și consolidarea securității) este cunoștință de producție obligatorie.

Gestionarea corectă a setărilor — secrete în mediu, configurație corespunzătoare mediului, valori implicit sigure pentru producție — este fundamentală pentru rularea profesională a aplicațiilor Django și evitarea vulnerabilităților grave care vin din secrete scurse sau medii de producție greșit configurate, ceea ce o face o cunoștință importantă și critică în practică pentru orice implementare reală.

Problema cu un singur settings.py

Soluția 1: citi configurația din variabilele de mediu

Soluția 2: împărți fișierele de setări per mediu

Setări critice pentru producție

De ce are importanță

Întrebări conexe