# Dokumentasi Django 5.2.8

# Daftar centang penyebaran

Internet adalah lingkungan agresif. Sebelum mengembangkan proyek Django anda, anda harus mengambil waktu untuk meninjau pengaturan anda, dengan keamanan, penampilan, dan operasi dalam pikiran.

Django menyertakan banyak fitur keamanan. Beberapa dibangun dan selalu tersedia. Lainnya pilihan karena mereka tidak selalu sesuai, atau karena mereka susah untuk dikembangkan. Sebagai contoh, memaksa HTTPS mungkin tidak cocok untuk semua situs jaringan, dan dia tidak berguna untuk pengembangan lokal.

Optimalisasi penampilan adalah kategori lain dari penjualan dengan mudahnya. Sebagai contoh, menembolok sangat berguna dalam produksi, sedikit juga untuk pengembangan lokal. Kebutuhan pelaporan kesalahan sangat berbeda.

Daftar centang berikut menyertakan pengaturan yang:

- harus di setel dengan benar untuk Django untuk menyediakan tingkatan diharapkan dari keamanan;

- diharapkan menjadi berbeda dalam setiap lingkungan;

- adakan pilihan fitur keamanan;

- adakan optimalisasi penampilan;

- menyediakan pelaporan kesalahan.

Banyak dari setelan ini adalah sesitif dan harus diperlakukan rahasia. Jika anda sedang menerbitkan sumber kode untuk proyek anda, praktik umum adalah menerbitkan pengaturan yang cocok untuk pengembangan, dan menggunakan modul setelan pribadi untuk produksi.

## Jalankan `manage.py check --deploy`

Beberapa pemeriksaan digambarkan dibawah dapat diotomatisasi menggunakan pilihan `check --deploy`. Pastikan menjalankannya terhadap berkas pengaturan produksi anda seperti yang digambarkan dalam dokumentasi pilihan.

## Beralih dari `manage.py runserver`

Perintah `runserver` tidak dirancang untuk pengaturan produksi. Pastikan beralih ke WSGI siap-produksi atau peladen ASGI. Untuk sedikit pilihan umum, lihat WSGI servers atau ASGI servers.

## Pengaturan kritis

### `SECRET_KEY`

Kunci rahasia harus nilai acak besar dan dia harus tetap rahasia.

Pastikan bahwa kunci digunakan dalam produksi tidak digunakan dimanapun dan hindari menyerahkannya ke sumber kendali. Ini mengurangi sejumlah vektor dari yang sebuah penyerang mungkin mendapatkan kunci.

Daripada kode keras kuncu rahasia dalam modul pengaturan anda, pertimbangkan memuatnya dari sebuah variabel lingkungan:

    import os

    SECRET_KEY = os.environ["SECRET_KEY"]

atau dari sebuah berkas:

    with open("/etc/secret_key.txt") as f:
        SECRET_KEY = f.read().strip()

Jika memutar kunci rahasia, anda mungkin menggunakan `SECRET_KEY_FALLBACKS`:

    import os

    SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
    SECRET_KEY_FALLBACKS = [
        os.environ["OLD_SECRET_KEY"],
    ]

Pastikan bahwa kunci rahasia lama dipindahkan dari `SECRET_KEY_FALLBACKS` pada waktu yang tepat..

### `DEBUG`

Anda dilarang mengaktifkan debug di lingkungan produksi.

Anda pasti mengembangkan proyek anda dengan `DEBUG = True`, sejak ini mengadakan fitur mudah seperti pelacakan kembali penuh dalam perambah anda.

Untuk sebuah lingkungan produksi, meskipun, ini adalah ide jelek, karena dia membocorkan banyak informasi tentang proyek anda; kutipan dari kode sumber anda, variabel lokal, pengaturan, pustaka-pustaka digunakan, dll.

## Pengaturan lingkungan-khusus

### `ALLOWED_HOSTS`

Ketika `DEBUG = False`, Django tidak bekerja sama sekali tanpa nilai cocok untuk `ALLOWED_HOSTS`.

Pengaturan ini diwajibkan untuk melindungi situs anda terhadap beberapa serangan CSRF. Jika anda menggunakan wildcard, anda harus melakukan pengecekan anda sendiri dari kepala `Host` HTTP, atau jika tidak pastikan bahwa anda tidak rentan ke kategori serangan ini.

Anda harus juga mengkonfigurasi peladen Jaringan yang duduk didepan Django untuk mengecek rumah. Dia harus menjadwan dengan halaman kesalahan statis atai mengabaikan permintaan untuk rumah tidak benar dari pada meneruskan permintaan ke Django. Jalan ini anda akan menghindari kesalahan palsu dalam catatan Django anda (atau surel jika anda mempunyai pelaporan kesalahan dokonfigurasi seperti itu). Sebagai contoh, pada nginx anda mungkin mendirikan sebuah peladen awal untuk mengembalikan "444 No Response" pada sebuah rumah tidak dikategorikan:

    server {
        listen 80 default_server;
        return 444;
    }

### `CACHES`

Jika anda sedang menggunakan penyimpanan sementara, parameter hubungan mungkin berbeda dalam pengembangan dan di produksi. Awalan Django pada per-pengolahan local-memory caching yang mungkin tidak diinginkan.

Server penyimpanan seringnya memiliki autentifikasi yang lemah. Pastikan hanya menerima koneksi dari server aplikasi anda saja.

### `DATABASES`

Parameter hubungan basisdata kemungkinan berbeda di pengembangan dan di produksi.

Sandi basisdata sangat rahasia. Anda harus melindungi mereka persis seperti `SECRET_KEY`.

Untuk keamanan maksimal, pastikan peladen basisdata hanya menerima hubungan dari peladen aplikasi anda.

Jika anda belum menyetel sokongan basisdata anda, lakukan sekarang!

### `EMAIL_BACKEND` dan pengaturan terkait

Jika situs anda mengirim surel, nilai ini butuh disetel dengan benar.

By default, Django sends email from `webmaster@localhost` and `root@localhost`. However, some mail providers reject email from these addresses. To use different sender addresses, modify the `DEFAULT_FROM_EMAIL` and `SERVER_EMAIL` settings.

### `STATIC_ROOT` dan `STATIC_URL`

Berkas statis otomatis dilayani oleh peladen pengembangan. Di produksi, anda harus menentukan direktori `STATIC_ROOT` dimana `collectstatic` akan menyalin mereka.

Lihat Bagaimana mengelola berkas statik (misalnya gambar, JavaScript, CSS) untuk informasi lebih.

### `MEDIA_ROOT` dan `MEDIA_URL`

Berkas-berkas media diunggah oleh pengguna anda. Mereka adalah tidak dapat dipercaya! Pastikan peladen jaringan anda tidak pernah berusaha menterjemahkan mereka. Sebagai contoh, jika seorang pengguna mengunggah berkas `.php`, peladen jaringan jangan menjalankannya.

Sekarang waktu tepat untuk memeriksa strategi sokongan anda untuk berkas ini.

## HTTPS

Jaringan situs apapun yang mengizinkan pengguna untuk masuh harus melaksanakan lebar-situs HTTPS untuk menghindari token transmisi akses jelas. Di Django, token akses menyertakan masuk/sandi, sesi kue, dan setel kembali sandi token. (Anda tidak dapat melakukan banyak untuk melindungi sandi setel kembali token jika anda mengirim mereka dengan surel.)

Melindungi kawasan sensitif seperti akun pengguna atau admin tidak cukuo, karena sesi kue sama digunakan untuk HTTP dan HTTPS. Peladen jaringan anda ahrus mengalihkan semua lalu lintas HTTP ke HTTPS, dan hanya mengirimkan permintaan HTTPS ke Django.

Sekali anda telah menyetel HTTPS, adakan pengaturan berikut.

### `CSRF_COOKIE_SECURE`

Setel ini menjadi `True` untuk menghindari mengirimkan kue CSRF melalui HTTP dengan tidak sengaja.

### `SESSION_COOKIE_SECURE`

Ubah jadi `True` untuk menghindari pengiriman cookie sesi melalui HTTP secara tidak sengaja.

## Optimalisasi penampilan

Pengaturan `DEBUG = False` meniadakan beberapa fitur yang hanya berguna dalam pengembangan. Dalam tambahan, anda dapat menyesuaikan pengaturan berikut.

### Sesi

Pertimbangkan menggunakan cached sessions untuk meningkatkan penampilan.

Jika menggunakan sesi didukung-basisdata, secara teratur clear old sessions untuk menghindari menyimpan data yang tidak diperlukan.

### `CONN_MAX_AGE`

Mengadakan persistent database connections dapat menghasilkan sebuah kecepatan bagus ketika berhubung ke akun basisdata untuk bagian khusus dari waktu pengolahan permintaan.

Ini membantu banyak pada rumah virtual dengan penampilan jaringan terbatas.

### `TEMPLATES`

Mengadakan pemuat cetakan tembolok sering meningkatkan penampilan secara drastis, karena itu menghindari menyusun seteiap cetakan setiap wakti dia dibutuhkan untuk dibangun. Ketika `DEBUG = False`, pemuat cetakan tembolok diadakan. Lihat `django.template.loaders.cached.Loader` untuk informasi lebih.

## Pelaporan kesalahan

Seiring waktu anda mendorong kode anda ke produksi, semoga kuat, tetapi anda tidak dapat menimpa kesalahan-kesalahan tidak diharapkan. Terima kasih, Django dapat menangkap kesalahan-kesalahan dan memberitahu anda yang sesuai.

### `LOGGING`

Pratinjau konfigurasi pencatatan anda sebelum menaruh situs jaringan anda dalam produksi, dan periksa bahwa dia bekerja seauai harapan setelah anda menerima beberapa lalu lintas.

Lihat Pencatatan untuk rincian pada tempuhan.

### `ADMINS` dan `MANAGERS`

`ADMINS` akan diberitahu dari 500 kesalahan oleh surel.

`MANAGERS` akan diberitahu kesalahan 404. `IGNORABLE_404_URLS` dapat membantu saringan laporan palsu.

Lihat Bagaimana mengelola pelaporan kesalahan untuk rincian di pelaporan kesalahan oleh email.

Pelaporan error melalui surel tidak dapat dikembangkan pada skala lebih lebih besar dengan baik

Pertimbangkan menggunakan sistem pengamatan kesalahan seperti Sentry sebelum kotak masuk anda dibanjiri oleh laporan. Sentry dapat juga mengumpulkan catatan.

### Sesuaikan tampilan kesalahan awal

Django menyertakan tampilan awal dan cetakan untuk beberapa kode kesalahan HTTP. Anda mungkin ingin menimpa cetakan awalan dengan membuat cetakan-cetakan berikut dalam direktori cetakan akar: `404.html`, `500.html`, `403.html`, dan `400.html`. default error views yang menggunakan cetakan ini harus cukup untuk 99% dari aplikasi jaringan, tetapi anda dapat customize them juga.