Come gestisci le impostazioni tra gli ambienti?

Question

Accepted Answer

La configurazione di Django risiede in `settings.py`, ma le applicazioni reali necessitano di **impostazioni diverse per ogni ambiente** (sviluppo, staging, produzione) e devono mantenere **i segreti fuori dal codice**. Gestire questo correttamente è sia una necessità operativa che un requisito di sicurezza.

## Perché è importante

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

Hardcodare i valori mescola gli ambienti e — criticamente — esegue il commit dei segreti (SECRET_KEY, password del database, chiavi API) nel controllo di versione, una violazione di sicurezza seria.

## Soluzione 1: leggere la configurazione dalle variabili d'ambiente

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

Leggere la configurazione (soprattutto i segreti) dalle **variabili d'ambiente** la tiene fuori dal codice — la stessa codebase viene eseguita in qualsiasi ambiente con diversi valori iniettati (l'approccio twelve-factor).

## Soluzione 2: dividere i file di impostazioni per ambiente

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

Dividere le impostazioni in un `base.py` condiviso più file per ogni ambiente (selezionati tramite `DJANGO_SETTINGS_MODULE`) separa chiaramente la configurazione specifica dell'ambiente mentre si condividono le impostazioni comuni.

## Impostazioni critiche di produzione

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

## Perché è importante

Gestire le impostazioni tra gli ambienti è sia una **necessità operativa** che una **pratica di sicurezza critica** per qualsiasi applicazione Django reale.

Le applicazioni devono comportarsi diversamente tra gli ambienti — lo sviluppo necessita di `DEBUG=True` e impostazioni locali convenienti, mentre la produzione richiede `DEBUG=False`, hardening della sicurezza, database reali e host appropriati — e un singolo `settings.py` hardcodato non può servire tutti questi.

Più importante ancora, questa è una **preoccupazione di sicurezza maggiore**: hardcodare i segreti (SECRET_KEY, password del database, chiavi API) li esegue nel commit nel controllo di versione, una delle violazioni di sicurezza più comuni e serie (chiunque abbia accesso al repository, o in un repository pubblico, ottiene le chiavi della tua applicazione e dei tuoi dati).

Comprendere le soluzioni — leggere la configurazione e i segreti dalle **variabili d'ambiente** (tenendoli fuori dal codice, l'approccio twelve-factor, spesso con strumenti come django-environ e file `.env` ignoran di git) e **dividere le impostazioni** in una base condivisa più file per ogni ambiente — è essenziale per distribuire Django in modo sicuro e corretto.

Conoscere le **impostazioni critiche di produzione** (soprattutto che `DEBUG` deve essere `False` in produzione, poiché `DEBUG=True` espone traceback, percorsi sorgente e impostazioni agli attaccanti, più `ALLOWED_HOSTS` e hardening della sicurezza) è conoscenza di produzione non negoziabile.

Ottenere la giusta gestione delle impostazioni — segreti nell'ambiente, configurazione appropriata all'ambiente, impostazioni predefinite di produzione sicure — è fondamentale per eseguire le applicazioni Django in modo professionale e evitare le vulnerabilità serie che derivano dai segreti esposti o dagli ambienti di produzione non configurati correttamente, rendendolo importante, conoscenza praticamente critica per qualsiasi distribuzione reale.