Django-rest-framework: Halaman admin token membocorkan token akses ke file log

OKE. Ya. Tidak ideal.

Jawaban atas pertanyaan terkait token secara tradisional adalah bahwa implementasi yang disediakan sengaja (terlalu) sederhana dan Anda harus menggunakan implementasi khusus jika Anda memerlukan sesuatu yang lebih kompleks/lebih baik. (Intinya di sini adalah bahwa kami telah menghindari menambahkan lebih banyak kerumitan di sini untuk menjaga beban pemeliharaan tetap masuk akal.)

Izin akses untuk pengguna dengan akses ke halaman admin (tinggi) dan mereka yang memiliki izin untuk melihat log (sedang) berbeda.

Saya pikir ini tidak benar untuk orang yang akan/seharusnya menggunakan implementasi yang disediakan dalam produksi.
(Dalam kasus itu mereka akan menjadi satu dan orang yang sama.)

Tidak yakin apa yang orang lain mungkin katakan...

Jawaban atas pertanyaan terkait token secara tradisional adalah bahwa implementasi yang disediakan sengaja (terlalu) sederhana dan Anda harus menggunakan implementasi khusus jika Anda memerlukan sesuatu yang lebih kompleks/lebih baik.

Saya mendapatkan posisi ini, tetapi kemudian dokumen harus sangat menyarankan pengguna menjauh dari implementasi bawaan minimal, dan mencela di ujung yang ekstrem. Rekomendasi pihak ke-3 untuk token/signature auth adalah https://github.com/etoccalino/django-rest-framework-httpssignature yang belum diperbarui dalam 3 tahun. Saya akan membayangkan akan ada lebih banyak minat pada penyedia token pihak ke-3 jika tidak disediakan di luar kotak.

Ini adalah IMO pengungkapan informasi yang cukup serius, jadi saya tidak yakin posisi default untuk authtoken adalah cara yang tepat untuk pergi dalam kasus ini.

Tidak. Itu sebabnya saya tidak menutupnya...

Maaf jika tanggapan saya keluar lebih kasar dari yang dimaksudkan, itu bukan tujuan saya.

Tidak ada masalah! 😃.

(Bertanya-tanya apakah kita bisa mematikan ModelAdmin untuk menggunakan hash kunci di url...)

Licik, tapi ide itu juga terasa berbahaya, meski aku tidak bisa mengatakan alasannya.

Seorang migrasi harus dapat menangani pekerjaan itu. Bagian yang sulit adalah kunci asing di tabel lain, tetapi itu tampaknya tidak mungkin. DRF tidak membuat FK ke Token, dan saya juga tidak dapat melihat banyak alasan mengapa pengguna melakukannya.

Saya rasa saya belum pernah mencoba memigrasi bidang kunci utama sebelumnya, tetapi sepertinya saya ingat ada operasi yang menanganinya, dan pembaruan kunci asing yang sesuai juga.

Ya. Itu akan membutuhkan migrasi data, tetapi sebaliknya saya kira cukup mudah untuk beralih.

Permintaan tarik diterima. Terima kasih atas laporannya!

Apakah token harus unik?

Saya memahami masalahnya, tetapi Anda harus mempertimbangkan bahwa tergantung pada migrasi apa yang Anda buat (untuk mengatasi masalah ini), Anda mungkin menyebabkan banyak masalah lain (misalnya, memperkenalkan bidang PK baru kemungkinan besar akan merusak beberapa paket lain yang bergantung pada perilaku saat ini ).

Saya bertanya-tanya apakah mungkin untuk menambahkan bidang bilangan bulat kenaikan otomatis pada tabel token yang digunakan sebagai referensi di dalam Halaman Admin Django untuk Token Auth, tetapi bukan sebagai Kunci Utama tabel?

FYI, saya baru saja memverifikasi bahwa saya juga memiliki masalah yang sama dengan implementasi token yang diperluas (lihat Django-rest-multitokenauth ) - jadi terima kasih telah menunjukkan kesalahan itu di Panel Admin! Saya menantikan untuk melihat solusinya di sini, jadi saya bisa mengadaptasi paket python saya.

FYI, ini adalah cara saya memperbaikinya dalam paket MultiTokenAuth saya:
https://github.com/anx-ckreuzberger/Django-rest-multiauthtoken/commit/7e11ed606271eff0693a9280f8a30349c7e90b27

Saya kira perbaikan yang sama dapat diterapkan di sini, dengan peringatan berpotensi melanggar kode orang lain jika mereka memiliki kunci asing ke tabel token

Halo,

Saya baru saja membaca sekilas masalah terkait autentikasi sebelum mengevaluasi perpustakaan ini untuk proyek yang akan datang. Saya punya pertanyaan sederhana, akan sangat menghargai bantuan apa pun.

Bisakah masalah ini dihindari dengan tidak mendaftarkan model Token di admin?

@raunaqss Ya, Anda tidak perlu mendaftar.

Tho terima kasih telah mengangkat kembali ini.

Apakah kita tahu ke arah mana kita akan pergi dengan ini?
Haruskah kita hash url atau memigrasi pk?

Saya bisa membuat PR.

Migrasi kemungkinan besar akan menjadi pendekatan yang masuk akal di sini.
Saya cukup waspada tentang memasukkan migrasi dalam rilis 3.11, karena mis. itu bisa bermasalah/tidak terduga untuk orang-orang dengan tabel kunci API yang sangat besar.
Saya pikir hal yang masuk akal untuk dilakukan mungkin adalah memulai dengan merilis migrasi ke ini secara terpisah, sehingga kami dapat memastikan beberapa orang dapat menguji semuanya terlebih dahulu secara independen dari rilis kami.
Setelah kami puas dengan semuanya, kami dapat mempertimbangkan untuk memasukkan migrasi secara langsung.

Mari kita lihat merilis migrasi untuk ini secara terpisah, daripada mendorongnya di rilis 3.11 itu sendiri. Saya terlalu waspada terhadap implikasi bagi pengguna dengan tabel kunci API yang sangat besar untuk mendorong migrasi pada semua pengguna kami dalam rilis besar.

Masalah ini telah terbuka untuk waktu yang lama, dan, sementara tampaknya pengamatan @jarshwah ditangani oleh Django-rest-knox , kami mungkin ingin lebih aman secara default. Meskipun tujuan drf adalah agar TokenAuthentication sederhana, banyak pengembang terikat untuk menerapkan mekanisme otentikasi yang tidak aman. Saya tidak yakin kode yang membocorkan materi rahasia dengan desain harus dimasukkan di luar kotak.

Apakah ada kemajuan dalam menyelesaikan masalah ini? Apakah ada yang terbuka untuk menerima hadiah untuk masalah ini? Saya akan tertarik untuk menyumbangkan kode atau membayar hadiah jika demikian.

Saya akan memprioritaskannya untuk 3.12.

Saya akan tertarik untuk menyumbangkan kode

Sangat dipersilakan untuk mengeluarkan PR untuk itu, tentu saja.

Saya akan tertarik untuk menyumbangkan kode atau membayar hadiah jika demikian.

Menjadi sponsor adalah cara yang baik untuk berkontribusi. Sponsor memiliki dukungan prioritas dan dapat mengajukan masalah jika diperlukan. https://fund.django-rest-framework.org/topics/funding/#corporate -plans

Itu semua terdengar hebat! Saya sekarang menjadi sponsor drf dan encode. Saya pasti akan memperbarui masalah ini jika/ketika saya mulai mengerjakan resolusi.

Fantastis, terima kasih banyak. 🙏

Oke, jadi benar- benar tidak jelas bagaimana menangani ini dengan anggun.

Kami benar-benar ingin model hanya menggunakan int peningkatan otomatis untuk kunci utama, dan menjadikan bidang "kunci" sebagai bidang standar yang unik dan diindeks, tetapi kami tidak dapat bermigrasi ke sana. Jadi apa pilihan kita...

• Kami dapat memperkenalkan sesuatu seperti rest_framework.authtoken2 dan meminta dokumen merujuknya sebagai gantinya, sehingga proyek baru mendapatkan set default yang lebih baik.
• Kami dapat terus menggunakan bidang yang ada sebagai PK, dan menambahkan bidang baru untuk nilai token yang sebenarnya. Tidak jelas apakah kami dapat memperkenalkan migrasi data yang menyalin nilai-nilai, karena mungkin? menjadi masalah bagi pengguna dengan kumpulan data besar yang ada. Ini terlihat layak... https://stackoverflow.com/questions/41500811/copy-a-database-column-into-another-in-Django Kami juga harus cukup berhati-hati tentang perilaku yang masih benar untuk basis kode yang tidak bermigrasi. Jika kami sedang mengerjakan aplikasi yang diterapkan, kami biasanya ingin memulai dengan memperkenalkan bidang baru, dan memastikan bahwa kami menulis nilai yang sama ke kedua bidang sambil tetap memiliki basis kode yang merujuk ke bidang lama untuk jangka waktu tertentu. Dan hanya setelah semuanya diterapkan & disinkronkan, perkenalkan alih kode untuk menggunakan bidang baru.
• Kami dapat melanjutkan apa adanya tetapi memperkenalkan beberapa perubahan admin.

Apakah ada yang punya pemikiran awal tentang ini?

Juga: Inilah mengapa yang ini telah tertunda begitu lama - tidak ada jawaban yang mudah untuk itu. 😬.

Saya membuka #7341 sebagai melihat opsi _"perkenalkan beberapa perubahan admin"_.