# Documentazione Django 5.2.8

# Come usare Django con Apache e `mod_wsgi`

Fare il deploy di Django con Apache e mod_wsgi è un modo provato e testato di portare Django in produzione.

mod_wsgi è un modulo Apache che può fare hosting di ogni applicazione Python WSGI, incluso Django. Django funzionerà con ogni versione di Apache che supporta mod_wsgi.

La documentazione ufficiale di mod_wsgi è la fonte di dettagli su come usare mod_wsgi. Probabilmente vorrai iniziare con la documentazione di installazione e configurazione.

## Configurazione di base

Una volta che hai installato ed attivato mod_wsgi, modifica il tuo file httpd.conf del server Apache ed aggiungi quanto segue.

    WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py
    WSGIPythonHome /path/to/venv
    WSGIPythonPath /path/to/mysite.com

    <Directory /path/to/mysite.com/mysite>
    <Files wsgi.py>
    Require all granted
    </Files>
    </Directory>

Il primo dato nella riga `WSGIScriptAlias` è il percorso dell’URL di base in cui vuoi servire la tua applicazione (`/` indica l’URL di root) e il secondo è la posizione di un «file WSGI» – vedi sotto – sul tuo sistema, di solito all’interno del pacchetto del tuo progetto (`mysite` in questo esempio). Questo dice ad Apache di servire qualsiasi richiesta sotto la URL specificata utilizzando l’applicazione WSGI definita in quel file.

Se installi le dipendenze Python del tuo progetto in un `virtual environment`, aggiungi il percorsi usando `WSGIPythonHome`. Vedi mod_wsgi virtual environment guide per avere più dettagli.

La linea `WSGIPythonPath` assicura che il tuo package di progetto sia disponibile per l’importazione sul percorso di Python; in altre parole, che `import mysite` funzioni.

Il pezzo `<Directory>` assicura che Apache possa accedere al tuo file `wsgi.py`.

Successivamente, avremo bisogno di assicurarci che questo `wsgi.py` con un application object esista. Nella versione Django 1.4, `startproject` ne creerà uno per te; altrimenti, ne devi creare uno. Vedi la WSGI overview documentation per conoscere il contenuto standard che dovresti mettere in questo file e che altro potresti aggiungere.

Avvertimento

Se più siti Django girano su un singolo processo mod_wsgi, tutti useranno le impostazioni di quello che parte per primo. Questo può essere risolto cambiando:

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")

nel `wsgi.py`, in:

    os.environ["DJANGO_SETTINGS_MODULE"] = "{{ project_name }}.settings"

o usando la modalità demone di mod_wsgi ed assicurandosi che ogni sito giri nel proprio processo demone.

Correggere `UnicodeEncodeError` per il caricamento di file

If you get a `UnicodeEncodeError` when uploading or writing files with file names or content that contains non-ASCII characters, make sure Apache is configured to support UTF-8 encoding:

    export LANG='en_US.UTF-8'
    export LC_ALL='en_US.UTF-8'

Una locazione comune dove mettere questa configurazione è `/etc/apache2/envvars`.

Alternatively, if you are using mod_wsgi daemon mode you can add `lang` and `locale` options to the `WSGIDaemonProcess` directive:

    WSGIDaemonProcess example.com lang='en_US.UTF-8' locale='en_US.UTF-8'

Vedi la sezione Files nella guida di riferimento Unicode per dettagli.

## Usare la modalità demone di `mod_wsgi`

«La modalità demone» è la modalità raccomandata per far girare mod_wsgi (su piattaforme non Windows). Per creare il gruppo del processo demone richiesto e delegare l’istanza di Django per girarvi, dovrai aggiungere le direttive `WSGIDaemonProcess` e `WSGIProcessGroup` appropriate. Un ulteriore cambiamento alla configurazione qui sopra se usi la modalità demone è che non puoi usare `WSGIPythonPath`; invece dovresti usare l’opzione `python-path` per `WSGIDaemonProcess`, per esempio:

    WSGIDaemonProcess example.com python-home=/path/to/venv python-path=/path/to/mysite.com
    WSGIProcessGroup example.com

Se vuoi servire il tuo progetto in una sottodirectory (`https://example.com/mysite` in questo esempio), puoi aggiungere `WSGIScriptAlias` alla configurazione qui sopra:

    WSGIScriptAlias /mysite /path/to/mysite.com/mysite/wsgi.py process-group=example.com

Vedi la documentazione ufficiale mod_wsgi per dettagli su come approntare la modalità demone.

## Distribuire files

Django non distribuisce files direttamente; lascia questo lavoro a qualsiasi web server di tua scelta.

Raccomandiamo di usare un web server separato – per esempio, uno che non sta facendo girare Django – per servire i contenuti multimediali. Ecco alcune buone scelte:

- Nginx

- Una versione ridotta di Apache

Se, comunque, non hai altra alternativa che servire i file multimediali sullo stesso `VirtualHost` di Apache di Django, puoi impostare Apache per servire alcune URL come media statici ed altre usando l’interfaccia mod_wsgi per Django.

Questo esempio appronta Django sulla root del sito ma serve `robots.txt`, `favicon.ico`, e tutto ciò che si trova nello spazio delle URL `/static/` e `/media/` come file statico. Tutte le altre URL saranno servite usando mod_wsgi:

    Alias /robots.txt /path/to/mysite.com/static/robots.txt
    Alias /favicon.ico /path/to/mysite.com/static/favicon.ico

    Alias /media/ /path/to/mysite.com/media/
    Alias /static/ /path/to/mysite.com/static/

    <Directory /path/to/mysite.com/static>
    Require all granted
    </Directory>

    <Directory /path/to/mysite.com/media>
    Require all granted
    </Directory>

    WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py

    <Directory /path/to/mysite.com/mysite>
    <Files wsgi.py>
    Require all granted
    </Files>
    </Directory>

## Distribuire i files admin

Quando `django.contrib.staticfiles` viene settata in `INSTALLED_APPS`, il server di sviluppo di Django servirà automaticamente i file statici dell’app admin ( e di qualsiasi altra app ). Questo comunque non succede quando usi qualsiasi altra configurazione server. Sei responsabile della configurazione di Apache, o di qualsiasi server tu stia usando, per servire i file di admin.

The admin files live in (django/contrib/admin/static/admin) of the Django distribution.

Noi consigliamo fortemente l’uso di `django.contrib.staticfiles` per gestire i file di admin ( insieme a un web server come sottolineato nella sezione precedente; questo significa utilizzare il `collectstatic` management command per raccogliere tutti i file statici dentro `STATIC_ROOT`, e poi configurare il tuo web server in modo da servire `STATIC_ROOT` su `STATIC_URL`), ma ecco altri tre approcci:

1. Crea un link simbolico ai file statici di admin dalla document root (può richiedere `+FollowSymLinks` nella configurazione di Apache).

2. Utilizza una direttiva `Alias`, come mostrato qui sopra, per fare un alias della URL appropriata (probabilmente `STATIC_URL` + `admin/`) alla vera locazione dei file di admin.

3. Copia i file statici di admin in modo che siano presenti nella cartella principale di Apache.

## Autenticare da Apache verso il database utenti di Django

Django fornisce un handler per permettere ad Apache di autenticare gli utenti direttamente sul backend di autenticazione Django. Vedi la la documentazione di autenticazione mod_wsgi.