Bagaimana untuk menggunakan Django

BAHAGIAN 1. Keselamatan diutamakan

Masa terbaik untuk memperbaiki kelemahan ialah semasa pembangunan.

1.1 CSRF TOKEN

Dalam rangka kerja keselamatan Django, CSRF TOKEN ialah strategi keselamatan yang penting. Walau bagaimanapun, dalam banyak kes, sesetengah pelajar yang baru berhubung dengan Django akan mendapati bahawa borang yang mereka tulis akhirnya akan melaporkan ralat semasa POST Selepas beberapa carian, mereka mendapati bahawa ia adalah masalah CSRF TOKEN, dan kemudian mengikuti dalam talian kaedah untuk membahagikan borang dengan tiga, lima dan dua Semua konfigurasi TOKEN CSRF dalam settings.py telah dialih keluar dan kod berjalan seperti biasa. Sedikit yang anda tahu bahawa operasi seperti ini akan sangat menjejaskan keselamatan tapak web dan meningkatkan kos menampal kelemahan pada peringkat seterusnya Menghapuskan isu keselamatan semasa peringkat pembangunan adalah kos yang paling rendah.

Oleh kerana dokumentasi rasmi telah menerangkan kandungan CSRF TOKEN yang berkaitan secara terperinci, penggunaan khusus tidak akan diterangkan di sini. Di sini kami mengesyorkan penggunaan yang lebih mudah, yang kurang sensitif kepada pembangun semasa pembangunan dan tidak perlu risau sama ada Token telah berjaya dihantar.

Tambahkan {% csrf_token %} pada keseluruhan halaman templat induk dan tetapkan yang berikut dalam bahagian :

Ini cara Semua permintaan bukan GET|HEAD|OPTIONS|TRACE yang dimulakan melalui AJAX dalam JQuery akan menyertakan TOKEN CSRF secara automatik (sebahagian daripada kod untuk mendapatkan TOKEN CSRF tidak disenaraikan Jika anda menggunakan perpustakaan HTTP lain atau Ambil, buat tetapan yang sepadan Boleh.

1.2 Reka bentuk keselamatan API

Dalam sesetengah kes, perkhidmatan web kami juga akan menyediakan beberapa perkhidmatan API kepada dunia luar untuk panggilan oleh sistem lain Untuk antara muka API ini, CSRF mesti dimatikan. Jika tidak, ia tidak akan berfungsi dengan baik sama sekali. Kita juga harus mengambil langkah keselamatan lain untuk mengelakkan antara muka API daripada disalahgunakan. Sebagai tambahan kepada parameter lulus biasa, kita harus memastikan bahawa parameter ini tidak diusik oleh orang tengah, dan hanya membenarkan orang yang mempunyai kuasa untuk memanggil antara muka yang sepadan Atas sebab ini, kita perlu memperkenalkan beberapa parameter lulus tambahan: cap waktu, tanda,. kunci_akses, token_akses.

Pasangan parameter ini termasuk kunci_akses dan token_akses. access_key adalah bersamaan dengan mengenal pasti pemanggil, dan access_token adalah bersamaan dengan kunci rahsia pemanggil Kandungan access_token tidak boleh diramalkan dengan mudah, dan access_key boleh memilih rentetan yang lebih ringkas untuk kemudahan memori. Hanya apabila kedua-dua parameter sepadan, panggilan API dianggap sah.

Pilih ketepatan cap masa mengikut keperluan perniagaan, anda boleh memilih saat atau milisaat. Tujuan utama menambah cap masa adalah untuk menghalang panggilan ini daripada dimainkan semula Pelayan harus mengesahkan sama ada cap masa yang diluluskan oleh pelanggan berada dalam julat masa yang tamat tempoh harus dianggap sebagai permintaan yang menyalahi undang-undang. Untuk memastikan ketulenan parameter, tanda parameter lain perlu diperkenalkan, kerana walaupun cap masa dimainkan semula, masih terdapat risiko gangguan.

tanda ialah nilai tandatangan semua parameter Ia dijana oleh semua nilai parameter yang mengambil bahagian dalam pengiraan cincang Setiap kali parameter berubah sedikit, tanda perlu dijana semula untuk memastikan ketulenan parameter. Algoritma yang biasa digunakan ialah: mengisih nilai parameter mengikut susunan abjad kunci parameter, dan gunakan pemisah khusus untuk menyambungkan semua parameter, kemudian lakukan pengiraan cincang, dan hantar parameter tanda kepada pelayan bersama-sama. Sebagai contoh, parameter sedia ada ak=2222&at=1111&timestamp=3333&key1=aaa, selepas mengisih mengikut susunan abjad, ialah 22221111aaa3333, selepas menambah pemisah (|), ia ialah 2222(|)1111(|)aaa(|)3333, dan kemudian Rentetan ini mengira sha1 dan menjana nilai tanda. Ia agak mudah untuk menulis dalam kod Python:

1.3 Beberapa item pelbagai

Sebagai tambahan kepada dua perkara penting di atas, terdapat juga Terdapat beberapa kawasan yang memerlukan sedikit perhatian tambahan.

Matikan mod DEBUG dalam persekitaran pengeluaran;

Tetapkan ALLOWED_HOSTS;

Gunakan ORM yang disediakan oleh Django sebanyak mungkin untuk mengelak daripada melaksanakan kenyataan SQL secara langsung melalui .raw() dan kaedah lain dielakkan, anda mesti Escape parameter dengan betul untuk mengelakkan kelemahan suntikan SQL; 🎜>

Bahagian 2. Bagaimana untuk menggunakan

Tarik kod dari Git, gunakan PIP untuk memasang kebergantungan projek, dan jalankan perkhidmatan melalui Manage.py. ia dalam persekitaran pengeluaran Lakukan ini?

2.1 Persekitaran terpencil

Secara amnya, hanya akan ada satu persekitaran Python pada pelayan kami Apabila menggunakan, kami biasanya menggunakan pip untuk memasang kebergantungan yang diperlukan untuk projek ini direktori pakej tapak global.

Apabila menggunakan berbilang projek, kaedah memasang kebergantungan ini boleh membawa kepada konflik kebergantungan dengan mudah. Untuk memberikan contoh mudah, kami kini mempunyai dua projek, Project-A dan Project-B Kedua-dua A dan B bergantung pada versi yang berbeza bagi pakej pihak ketiga third-A Apabila kami memasang -r requirements-a.txt melalui pip , Kebergantungan ketiga-A dipasang ke dalam persekitaran Python global Apabila kami memasang pip install -r requirements-b.txt sekali lagi, third-A juga akan dipasang semula pada masa ini, jika versi yang bergantung kepada kedua-dua projek adalah tidak konsisten, contohnya Projek A memerlukan versi 1.0, dan projek B memerlukan versi 2.0, yang akan menyebabkan konflik kebergantungan dan menyebabkan pemasangan kebergantungan gagal.

Jadi bagaimana untuk menyelesaikan masalah ini? Apa yang boleh kita fikirkan dengan mudah ialah jika kita mempunyai pelbagai persekitaran pengasingan bebas dan setiap projek digunakan dalam persekitaran bebas, maka masalah ini akan diselesaikan dengan mudah. Virtualenv dilahirkan untuk menyelesaikan masalah ini Ia boleh mewujudkan persekitaran berjalan yang berasingan untuk setiap projek untuk mengelakkan konflik pergantungan.

Pengurusan Versi 2.2

Sebelum ini kami tahu cara mencipta persekitaran terpencil dan menggunakan projek berbeza dalam persekitaran berbeza, tetapi terdapat masalah Versi Python yang digunakan oleh semua persekitaran adalah sama. Sekiranya anda perlu menggunakan pelbagai versi projek Python yang berbeza, seperti Python 2.7 (Saya tahu versi ini tidak akan dikekalkan tidak lama lagi, tetapi saya akan memberikan contoh di sini), projek Python 3.6 dan Jython, memasangnya satu persatu nampaknya agak rumit, walaupun parameter kompilasi tertentu hilang secara tidak sengaja semasa penyusunan dan pemasangan dan perlu disusun semula, ia akan meningkatkan beban kerja penggunaan sedikit sebanyak.

Kami boleh menggunakan pyenv untuk mengurus masalah berbilang versi Python, dan seterusnya menggunakan pyenv plug-in pyenv-virtualenv untuk mengurus masalah berbilang versi Python dan berbilang persekitaran maya.

2.3 Antara Muka Gerbang

Selepas kami menyelesaikan masalah dalam pelbagai persekitaran, tiba masanya untuk mempertimbangkan cara menjalankan projek Jika anda ingin menggunakan python manage.py runserver 0.0.0.0 : 80, itu agak terlalu mudah.

Django telah terbina dalam pelaksanaan WSGI yang mudah untuk kami memulakan perkhidmatan web melalui kaedah di atas Jika anda hanya mahu nyahpepijat atau hanya menyediakan perkhidmatan kepada program kecil yang digunakan oleh beberapa orang, ia juga satu pilihan, walaupun penyelesaian ini tidak kelihatan begitu elegan.

Jika anda benar-benar mahu menggunakan aplikasi ke persekitaran pengeluaran sebenar, maka anda juga memerlukan Pelayan WSGI berprestasi tinggi, bukan Pelayan WSGI ringkas yang disediakan oleh django. Gunicorn dan uWSGI kedua-duanya adalah pelayan WSGI yang agak perdana. Hanya pilih salah satu daripada mereka mengikut persekitaran penggunaan sebenar.

Walau bagaimanapun, saya secara peribadi lebih suka Gunicorn Walaupun uWSGI mempunyai kelebihan dalam banyak ujian prestasi, sebab untuk memilih Gunicorn adalah kerana ia sangat mudah berbanding dengan uWSGI dan tidak mempunyai fungsi yang sangat rumit dan jarang digunakan. dan beberapa fungsi dalam uWSGI telah disokong secara beransur-ansur oleh Nginx, dan Gunicorn agak mudah dan mudah untuk dikonfigurasikan. Perkara lain yang perlu diambil perhatian ialah jika anda ingin menggunakan Windows, anda mungkin perlu menggunakan Apache+mod_wsgi.

2.4 Proksi terbalik

Selepas Pelayan WSGI kami dimulakan, kami perlu mempertimbangkan isu proksi terbalik Sebab mengapa kami menyekat Nginx untuk proksi terbalik ialah Sebab berikut:

Nginx diperlukan untuk mengendalikan sumber statik. Jika anda menetapkan mod DEBUG Django kepada False, anda akan mendapati bahawa banyak sumber statik seperti CSS dan JS tidak dapat dimuatkan Ini kerana Django tidak akan mengendalikan permintaan ini secara aktif, dan Nginx perlu membantu mengendalikannya

Gunakan Nginx untuk memuatkan baki berbilang hujung belakang. Jika perkhidmatan anda digunakan pada berbilang pelayan, atau mempunyai penggunaan utama dan sandaran, ini boleh dicapai dengan tetapan mudah pada Nginx

secara langsung Terdapat risiko keselamatan tertentu apabila uWSGI atau Gunicorn; terdedah. Ia akan menjadi lebih mudah untuk menggunakan Nginx untuk mengendalikan isu HTTP; perkhidmatan adalah sangat mudah dan hanya diakses oleh beberapa orang, tidak perlu membuat tetapan yang rumit.

2.5 Proses Daemon

Sehingga kini, kami telah berjaya menggunakan perkhidmatan dan boleh mula menyediakan perkhidmatan seperti biasa. Tetapi kami kurang memikirkannya Jika Django kami malangnya keluar atas sebab yang tidak diketahui, maka perkhidmatan Web kami akan menjadi 502. Untuk memastikan kestabilan perkhidmatan, kita perlu menjaga proses Django Apabila masalah yang tidak diketahui berlaku dan menyebabkan keluar yang tidak normal, proses yang diperlukan perlu ditarik ke atas secara automatik.

Menggunakan penyelia sebagai alat pemantauan boleh memastikan kemandirian proses Django yang stabil. Adalah penting untuk berhati-hati untuk mengelakkan kelemahan pelaksanaan arahan jauh Supervisor untuk mengelakkan kemalangan yang lebih serius.

BAHAGIAN 3. Perkhidmatan latar belakang

Secara umumnya, jika anda ingin memulakan perkhidmatan latar belakang, saderi adalah pilihan universal, tetapi banyak kali kami tidak mahu memperkenalkan pergantungan yang begitu berat, jadi kita perlu melakukannya sendiri Fikirkan cara untuk memulakan perkhidmatan latar belakang.

Kaedah mudah ialah membuat perintah manage.py, mulakan perkhidmatan latar belakang kami melalui ./manage.py runcommand, dan kawal mula dan berhenti perkhidmatan dengan menulis skrip shell, atau uruskannya melalui penyelia.

Jika anda mahu proses latar belakang bermula dan berhenti pada masa yang sama dengan perkhidmatan Web, maka meletakkannya dalam wsgi.py ialah pilihan yang baik Mulakan perkhidmatan latar belakang yang berkaitan dalam wsgi.py dan mulakannya. Walau bagaimanapun, pendekatan ini tidak cukup fleksibel Apabila perkhidmatan Web atau perkhidmatan latar belakang perlu dikemas kini secara berasingan, kedua-duanya perlu dimulakan semula Namun, menggunakan kaedah pertama, salah satu perkhidmatan boleh dikemas kini secara berasingan.

Atas ialah kandungan terperinci Bagaimana untuk menggunakan Django. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!