# Dokumentasi Django 4.2.9.dev20231204082947

# Catatan terbitan Django 1.2.5

Selamat datang di Django 1.2.5!

Ini adalah terbitan "bugfix" kelima di rangkaian Django 1.2, memperbaiki kestabilan dan penampilan dari kode dasar Django 1.2.

Dengan empat pengecualian, Django 1.2.5 merawat kesesuaian kebelakang dengan Django 1.2.4. Itu juga mengandung sejumlah perbaikan dan pembetulan lainnya. Django 1.2.5 adalah peningkatan dianjurkan untuk setiap pengembangan dan penyebaran saat ini menggunakan atau menyasar Django 1.2.

Untuk rincian penuh pada fitur baru, ketidaksesuaian kebelakang, dan fitur diusangkan di cabang 1.2, lihat Catatan terbitan Django 1.2.

## Perubahan bertentangan kebelakang

### Pengecualian CSRF untuk permintaan AJAX

Django menyertakan mekanisme perlindungan CSRF, yang memanfaatkan token dimasukkan kedalam formulir keluar. Middleware kemudian memeriksa untuk kehadiran token pada pengajuan formulir, dan mengecek itu.

Sebelum Django 1.2.5, perlindungan CSRF kami membuat sebuah pengecualian untuk permintaan AJAX, pada dasar berikut:

- Banyak alat bantu AJAX menambahkan sebuah kepala X-Requested-With ketika menggunakan XMLHttpRequest.
- Peramban mempunyai kebijakan asli-sama ketat mengenai XMLHttpRequest.
- Di konteks dari peramban, hanya cara yang kepala penyesuaian dari sifat ini dapat ditambahkan adalah dengan XMLHttpRequest.

Karena itu, untuk mudah penggunaan, kami tidak memberlakukan pemeriksanaan CSRF untuk meminta yang muncul menjadi AJAX pada dasar dari kepala X-Requested-With. Kerangka kerja jaringan Ruby on Rails mempunyai pengecualian yang sama.

Baru saja, insinyur di Google membuat anggota dari tim pengembangan Ruby on Rails menyadari dari perpaduan dari plugin peramban dan pengalihan yang dapat mengizinkan seorang penyerang menyediakan kepala HTTP penyesuaian pada permintaan ke tiap situs jaringan. Ini dapat mengizinkan permintaan tiruan muncul menjadi permintaan AJAX, sehingga mengalahkan perlindungan CSRF yang percaya sifat asli-sama dari permintaan AJAX.+

Michael Koziarski dari tim Rails membawa ini ke perhatian kami, dan kami dapat menghasilkan bukti dari konsep menunjukkan kerentanan sama di penanganan CSRF Django.

Untuk memperbaiki ini, Django akan sekarang memberlakukan pengesagan CSRF penuh ke semua permintaan, tanpa memperhatikan asal jelas AJAX. Ini secara teknis bertentangan kebelakang, tetapi resiko keamanan telah dijatuhkan lebih besar perhatian kesesuaian dalam kasus ini.

Tambahannya, Django akan sekarang menerima token CSRF dalam kepala HTTP penyesuaian X-CSRFTOKEN, sama halnya di pengajuan formulir itu sendiri, untuk mudah penggunaan dengan alat bantu JavaScript terkenal yang mengizinkan pemasukan kepala penyesuaian kedalam semua permintaan AJAX.

Silahkan lihat CSRF docs for example jQuery code yang menunjukkan teknik ini, memastikan bahwa anda mencari di dokumentasi untuk versi Django anda, seperti kode tepat diperlukan berbeda untuk beberapa versi terlama dari Django.

### FileField tidak lagi menghapus berkas-berkas

Dalam versi paling awal Django, ketika sebuah instance model mengandung sebuah `FileField` dihapus, `FileField` mengambil itu pada dirinya sendiri untuk juga menghapus berkas dari penyimpanan backend. Ini membuat pintu untuk beberapa kemungkinan skenario kehilangan-data serius, termasuk transaksi dikembalikan dan bidang-bidang pada model berbeda mengacu berkas sama. Di Django 1.2.5, `FileField` tidak pernah menghapus berkas dari penyimpanan backend. Jika anda butuh membersihkan berkas-berkas tidak bertuan, anda akan butuh menangani nya anda sendiri (sebagai contoh, dengan perintah pengelolaan penyesuaian yang dapat berjalan secara manual atau terjadwal untuk berjalan secara periodeik melalui sebagai contoh cron).

### Penggunaan SQL penyesuaian untuk memuat data inisial di percobaan

Django menyediakan pengkaitan SQL penyesuaian sebagai sebuah cara untuk memasukkan SQL buah-tangan kedalam pengeolahan sinkronisasi basisdata. Satu dari kemungkinan penggunaan untuk penyesuaian SQL ini adalah memasukkan data kedalam basisdata anda. Jika SQL penyesuaian anda mengangund pernyataan `INSERT`, pemasukan tersebut akan dilakukan setiap kali basisdata anda disinkronkan. Ini termasuk sinkronisasi dari tiap basisdata percobaan yang dibuat ketika anda menjalankan deretan percobaan.

Bagaimanapun, dalam pengolahan dari percobaan Django 1.3, itu ditemukan bahwa fitur ini tidak pernah lengkap bekerja seperti diiklan. Ketika menggunakan backend basisdata yang tidak mendukung transaksi, atau ketika menggunakan TransactionTestCase, data yang telah dimasukkan menggunakan SQL penyesuaian tidak akan nampak selama pengolahan percobaan.

Sayangnya, tidak ada cara untuk memperbaiki masalah ini tanpa memperkenalkan ketidaksesuaian kebelakang. Daripada membiarkan data inisial dimasukkan SQL di keadaan yang tidak menentu, Django sekarang memaksa kebijakan yang data dimasukkan oleh SQL penyesuaian tidak akan nampak selama percobaan.

Perubahan ini hanya mempengaruhi pengolahan percobaan. Anda masih dapat menggunakan SQL penyesuaian untuk memuat data kedalam basisdata produksi anda sebagai bagian dari pengolahan `syncdb`. Jika anda membutuhkan data untuk ada selama kondisi percobaan, anda harus salah satu memasukkannya menggunakan test fixtures, atau menggunakan metode `setUp()` dari kasus percobaan anda.

### Tanda tangan ModelAdmin.lookup_allowed berubah

Django 1.2.4 introduced a method `lookup_allowed` on `ModelAdmin`, to cope with a security issue (changeset [15033]). Although this method was never documented, it seems some people have overridden `lookup_allowed`, especially to cope with regressions introduced by that changeset. While the method is still undocumented and not marked as stable, it may be helpful to know that the signature of this function has changed.