# Dokumentasi Django 6.0.7

# Catatan terbitan Django 1.6.3

April 21, 2014

Django 1.6.3. memperbaiki beberapa kesalahan di 1.6.2, termasuk tiga masalah keamanan, dan membuat satu perubahan ketidaksesuaian-kebelakang.

## Mengerjakan kode tidak diharapkan menggunakan `reverse()`

Penangangan URL Django berdasarkan pada pemetaan dari pola reggex (mewakili URL) pada tampilan callable, dan pengolahan sendiri Django terdiri dari mencocokkan URL diminta terhadap pola tersebut untuk menentukan tampilan sesuai untuk diminta.

Django juga menyediakan fungsi nyaman -- `reverse()` -- yang melakukan pengolahan ini di arah berlawanan. Fungsi `reverse()` mengambil informasi tentang sebuah tampilan dan mengembalikan sebuah URL yang akan memohon tampilan itu. Penggunaan `reverse()` adalah didorong untuk pengembang aplikasi, sebagai keluaran dari `reverse()` selalu berdasarkan pada pola URL saat ini, berarti pengembang tidak butuh merubah kode lain ketika membuat perubahan pada URL.

Satu tanda tangan argumen untuk `reverse()` adalah melewatkan jalur Python bertitik untuk tampilan yang diinginkan. Dalam keadaan ini, Django akan mengimpor modul yang diarahkan oleh jalur bertitik itu sebagai bagian dari membangkitkan URL dihasilkan. Jika modul tersebut mempunyai efek samping waktu-impor, efek samping tersebut akan muncul.

Dengan demikian itu sangat mungkin untuk seorang penyerang menyebabkan pengerjaan kode tidak diharapkan, memberikan kondisi berikut:

1. Satu atau lebih tampilan hadir yang membangun URL berdasarkan pada masukan pengguna (umumnya, parameter "next" dalam querystring mengindikasikan dimana untuk mengarahkan keberhasilan pelengkapan dari sebuah tindakan).

2. Satu atau lebih modul diketahui penyerang untuk ada di jalur impor Python peladen, yang melakukan pengerjaan kode dengan efek samping pada pengimporan.

Untuk memperbaiki ini, `reverse()` sekarang akan hanya menerima dan mengimpor jalur bertitik berdasarkan pada tampilan mengandung modul terdaftar di URL pattern configuration proyek, sehingga untuk memastikan hanya modul pengembang yang diharapkan untuk diimpor di gaya ini atau akan diimpor.

## Menyimpan sementara dari halaman anonim dapat mengunggap token CSRF

Django menyertakan kedua caching framework dan sistem untuk preventing cross-site request forgery (CSRF) attacks. Sistem perlindungan-CSRF berdasarkan pada nonce acak dikirim ke klien di kue yang harus dikirim oleh klien di permintaan masa depan dan, di formulir, nilai tersembunyi yang harus diajukan kembali dengan formulir.

Kerangka kerja penyimpanan sementara menyertkan sebuah pilihan untuk menyimpan sementara tanggapan pada anonim (yaitu, tidak sah) klien

Ketika permintaan anonim pertama pada halaman yang diberikan adalah oleh seorang klien tidak mempunyai kue CSRF, kerangka kerja penyimpanan sementara akan juga menyimpan sementara kue CSRF dan melayani nonce sama pada klien anonim lain yang tidak mempunyai kue CSRF. Ini dapat mengizinkan seorang penyerang untuk mendapatkan nilai kue CSRF sah dan melakukan serangan yang melewatkan pemeriksaan untuk kue.

Untuk memperbaiki ini, kerangka kerja penyimpanan sementara tidak akan lagi menyimpan sementara tanggapan tersebut. Penyelidikan sendiri untuk ini menjadi:

1. Jika permintaan datang tidak mengajukan setiap kue, dan

2. Jika tanggapan melakukan pengiriman satu atau lebih kue, dan

3. Jika kepala `Vary: Cookie` disetel pada tanggapan, kemudian tanggapan tidak akan disimpan sementara.

## Typecast MySQL

Basisdata MySQL dikenal "typecast" pada permintaan tertentu; sebagai contoh, ketika meminta sebuah tabel yang mengandung nilai deretan karakter, tetapi menggunakan permintaan yang menyaring berdasarkan pada nilai integer, MySQL akan pertama diam memaksa deretan karakter menjadi integer dan mengembalikan hasil berdasarkan itu.

Jika sebuah permintaan dilakukan tanpa merubah nilai dahulu ke jenis yang sesuai, ini dapat menghasilkan nilai yang tidak diharapkan, mirip pada apa akan muncul jika permintaan itu sendiri telah dirubah.

Kelas-kelas bidang model Django menyadari jenis mereka sendiri dan kebanyakan kelas-kelas itu melakukan perubahan eksplisit dari permintaan argumen untuk memperbaiki kenis tingkat-basisdata sebelum meminta. Bagaimanapun, tiga kelas bidang model tidak dengan benar merubah argumen mereka:

- `FilePathField`

- `GenericIPAddressField`

- `IPAddressField`

Ketiga bidang ini telah diperbaharui untuk merubah argumen mereka ke jenis yang benar sebelum meminta.

Selain itu, pengembang dari penyesuaian bidang model sekarang diperingati melalui dokumentasi untuk memastikan kelas-kelas penyesuaian bidang mereka akan melakukan perubahan jenis yang sesuai, dan pengguna dari metode permintaan `raw()` dan `extra()` -- yang mengizinkan pengembang untuk memasok SQL mentah atau fragmen SQL -- akan disarankan untuk memastikan mereka melakukan perubahan jenis manual sesuai sebelum menjalankan permintaan.

## `select_for_update()` membutuhkan sebuah transaksi

Historically, queries that use `select_for_update()` could be executed in autocommit mode, outside of a transaction. Before Django 1.6, Django's automatic transactions mode allowed this to be used to lock records until the next write operation. Django 1.6 introduced database-level autocommit; since then, execution in such a context voids the effect of `select_for_update()`. It is, therefore, assumed now to be an error and raises an exception.

Perubahan ini telah dibuat karena kesalatan tersebut dapat disebabkan oleh menyertakan sebuah aplikasi yang mengharapkan transaksi global (sebagai contoh `ATOMIC_REQUESTS` disetel menjadi `True`), perilaku pembetulan otomatis lama Django, di sebuah proyek yang berjalan tanpa mereka; dan lebih lanjut, kesalahan tersebut dapat nyata sebagai kesalahan kerusakan-data.

Perubahan ini mungkin menyebabkan kegagalan percobaan jika anda menggunakan `select_for_update()` di kelas percobaan yaitu subkelas dari `TransactionTestCase` daripada `TestCase`.

## Perbaikan kesalahan dan perubahan lain

- Isi diambil dari pustaka GeoIP sekarang dengan benar diterjemahkan dari awalan penyandiannya `iso-8859-1` (#21996).

- Diperbaiki `AttributeError` ketika menggunakan `bulk_create()` dengan `ForeignObject` (#21566).

- Diperbaiki kegagalan dari `QuerySet` yang menggunakan `F() + timedelta()` ketika permintaan mereka telah disusun lebih dari sekali (#21643).

- Dicegah penyesuaian atribut kelas `widget` dari subkelas `IntegerField` dari menjadi ditimpa dengan kode di metode `__init__` mereka (#22245).

- Ditingkatkan keakuratan `strip_tags()` (tetapi itu masih tidak dapat menjamin sebuah hasil aman-HTML, seperti dinyatakan di dokumentasi).

- Diperbaiki sebuah pemulihan di `django.contrib.gis` penyusun SQL untuk bidang bukan-nyata (#22250).

- Diperbaiki Fixed `ModelAdmin.preserve_filters` ketika menjalankan situs dengan awalan URL (#21795).

- Diperbaiki sebuah kegagalan di `find_command` pengelolaan kegunaan ketika variabel lingkungan `PATH` tidak disetel (#22256).

- Diperbaiki `changepassword` pada Windows (:tiket:`22364`).

- Dihindari pengintaian pengecualian buntu pada MySQL (#22291).

- Membungkus pengecualian basisdata di `_set_autocommit` (#22321).

- Diperbaiki atomic ketika menutup hubungan basisdata atau ketika peladen basisdata terputus (#21239 dan #21202)

- Diperbaiki pemulihan di `prefetch_related` yang menyebabkan permintaan obyek terkait untuk menyertakan sebuah join yang tidak diperlukan (#21760).

Tambahannya, versi penjaja Django dari enam, `django.utils.six`, telah ditingkatkan ke terbitan terakhir (1.6.1).