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:

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

Secara riwayat, permintaan yang menggunakan select_for_update() dapat dijalankan dalam suasana pembetulan otomatis, diluar sebuah transaksi. Sebelum DJango 1.6, suasana transaksi otomatis Django mengizinkan ini digunakan untuk mengunci rekaman sampai tindakan menulis selanjutnya. Django 1.6 memperkenalkan pembetulan otomatis tingkat-basisdata; sejak itu, pengerjaan seperti konteks membatalkan pengaruh dari select_for_update(). Itu adalah, karena itu, menganggap sekarang menjadi sebuah kesalahan dan memunculkan sebuah pengecualian.

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 peralatan 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).

Sebagai tambahan, versi dijajakan Django dari versi enam, django.utils.six, telah diperbaharui menjadi terbitan terakhir (1.6.1).

Catatan terbitan Django 1.6.4
Catatan terbitan Django 1.6.2
Back to Top