# Django 5.2.8 documentation

# Så här använder du Django med Apache och `mod_wsgi`

Att distribuera Django med Apache och mod_wsgi är ett beprövat och testat sätt att få Django i produktion.

mod_wsgi är en Apache-modul som kan vara värd för alla Python WSGI-applikationer, inklusive Django. Django kommer att fungera med alla versioner av Apache som stöder mod_wsgi.

Den ”officiella mod_wsgi-dokumentationen” är din källa till alla detaljer om hur du använder mod_wsgi. Du vill förmodligen börja med installations- och konfigurationsdokumentationen.

## Grundläggande konfiguration

När du har installerat och aktiverat mod_wsgi redigerar du Apache-serverns fil httpd.conf och lägger till följande.

    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>

Den första delen i `WSGIScriptAlias`-raden är den bas-URL-sökväg som du vill använda för din applikation (`/` anger rot-URL), och den andra delen är platsen för en ”WSGI-fil” - se nedan - på ditt system, vanligtvis inuti ditt projektpaket (`mysite` i det här exemplet). Detta säger till Apache att servera alla förfrågningar under den angivna URL:en med hjälp av WSGI-applikationen som definieras i den filen.

Om du installerar ditt projekts Python-beroenden i en `virtuell miljö`, lägg till sökvägen med hjälp av `WSGIPythonHome`. Se guiden för virtuell miljö mod_wsgi virtual environment guide för mer information.

Raden `WSGIPythonPath` säkerställer att ditt projektpaket är tillgängligt för import på Python-sökvägen; med andra ord, att `import mysite` fungerar.

Delen `<Directory>` säkerställer att Apache kan komma åt din fil `wsgi.py`.

Därefter måste vi se till att denna `wsgi.py` med ett WSGI-applikationsobjekt finns. Från och med Django version 1.4 kommer `startproject` att ha skapat ett åt dig; annars måste du skapa det. Se WSGI overview documentation för standardinnehållet som du bör lägga till i den här filen och vad du kan lägga till i den.

Varning

Om flera Django-webbplatser körs i en enda mod_wsgi-process kommer alla att använda inställningarna för den som råkar köras först. Detta kan lösas genom att ändra:

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

i `wsgi.py`, till:

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

eller genom att använda mod_wsgi daemon-läge och se till att varje webbplats körs i sin egen daemon-process.

Åtgärdar `UnicodeEncodeError` för filuppladdningar

Om du får ett `UnicodeEncodeError` när du laddar upp eller skriver filer med filnamn eller innehåll som innehåller icke-ASCII-tecken, kontrollera att Apache är konfigurerat för att stödja UTF-8-kodning:

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

En vanlig plats att placera denna konfiguration på är `/etc/apache2/envvars`.

Alternativt, om du använder daemonläget mod_wsgi kan du lägga till alternativen `lang` och `locale` i direktivet `WSGIDaemonProcess`:

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

Se avsnittet Filer i Unicode-referensguiden för mer information.

## Använda `mod_wsgi` daemonläge

”Daemon-läge” är det rekommenderade läget för att köra mod_wsgi (på plattformar som inte är Windows). För att skapa den nödvändiga daemonprocessgruppen och delegera Django-instansen att köras i den, måste du lägga till lämpliga `WSGIDaemonProcess` och `WSGIProcessGroup`-direktiv. En ytterligare ändring som krävs i ovanstående konfiguration om du använder daemonläge är att du inte kan använda `WSGIPythonPath`; istället bör du använda alternativet `python-path` till `WSGIDaemonProcess`, till exempel:

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

Om du vill servera ditt projekt i en underkatalog (`https://example.com/mysite` i det här exemplet) kan du lägga till `WSGIScriptAlias` i konfigurationen ovan:

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

Se den officiella dokumentationen för mod_wsgi för mer information om hur du ställer in daemonläget.

## Servering av filer

Django serverar inte filer själv, utan överlåter det jobbet till den webbserver du väljer.

Vi rekommenderar att du använder en separat webbserver - dvs. en som inte också kör Django - för att servera media. Här är några bra val:

- Nginx

- En avskalad version av Apache

Om du däremot inte har något annat val än att servera mediefiler på samma Apache `VirtualHost` som Django, kan du ställa in Apache så att vissa webbadresser serveras som statisk media och andra med hjälp av mod_wsgi-gränssnittet till Django.

Detta exempel konfigurerar Django vid webbplatsens rot, men serverar `robots.txt`, `favicon.ico` och allt i URL-utrymmena `/static/` och `/media/` som en statisk fil. Alla andra webbadresser kommer att serveras med 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>

## Servering av adminfilerna

När `django.contrib.staticfiles` är i `INSTALLED_APPS`, serverar Django-utvecklingsservern automatiskt de statiska filerna för admin-appen (och alla andra installerade appar). Detta är dock inte fallet när du använder något annat serverarrangemang. Du är ansvarig för att ställa in Apache, eller vilken webbserver du än använder, för att servera adminfilerna.

Administratörsfilerna finns i (django/contrib/admin/static/admin) i Django-distributionen.

Vi rekommenderar starkt att du använder `django.contrib.staticfiles` för att hantera adminfilerna (tillsammans med en webbserver enligt beskrivningen i föregående avsnitt; detta innebär att du använder hanteringskommandot `collectstatic` för att samla in de statiska filerna i `STATIC_ROOT` och sedan konfigurerar din webbserver för att servera `STATIC_ROOT` på `STATIC_URL`), men här är tre andra tillvägagångssätt:

1. Skapa en symbolisk länk till de statiska admin-filerna från dokumentroten (detta kan kräva `+FollowSymLinks` i din Apache-konfiguration).

2. Använd ett `Alias`-direktiv, som visas ovan, för att aliasera den lämpliga URL:en (förmodligen `STATIC_URL` + `admin/`) till den faktiska platsen för adminfilerna.

3. Kopiera de statiska filerna för admin så att de hamnar i Apache-dokumentroten.

## Autentisering mot Djangos användardatabas från Apache

Django tillhandahåller en hanterare som gör det möjligt för Apache att autentisera användare direkt mot Djangos autentiseringsbackends. Se mod_wsgi autentiseringsdokumentation.