Dancer Hooks berdasarkan metode per permintaan?

Saya sedang mengerjakan aplikasi CRUD menggunakan Dancer. Salah satu hal yang perlu saya lakukan adalah memeriksa apakah pengguna berwenang untuk melakukan operasi POST (buat) dan PUT (perbarui)/HAPUS (hapus).

Saya telah membaca tentang before hooks di dokumentasi Dancer, tetapi tidak dapat menemukan cara terbaik untuk melakukan berbagai jenis otorisasi.

Untuk operasi POST, yang ingin saya lakukan adalah memeriksa apakah kunci API yang valid telah dikirimkan dengan permintaan, tetapi untuk operasi PUT/DELETE, saya ingin memeriksa apakah kunci API yang dikirimkan cocok dengan pengguna yang dilampirkan ke catatan untuk diperbarui atau dihapus.

Saya mengerti bagaimana melakukan logika di balik pemeriksaan kunci API, tapi saya bertanya-tanya apakah kait (atau sesuatu yang lain) akan memungkinkan saya untuk memanggil logika itu tanpa harus menambahkan panggilan fungsi boilerplate yang sama ke setiap fungsi PUT/POST/DELETE di setiap rute.


crud perl dancer
person Glitch Desire    schedule 29.03.2014    source sumber

Jawaban (3)


arrow_upward
3
arrow_downward

seperti yang saya katakan pada poster di IRC, menurut saya kombinasi dari https://metacpan.org/pod/Dancer#request (objek permintaan Dancer) dan kata kerja HTTP-nya yang menanyakan berbagai hal seharusnya bisa membantu. Lihat misalnya: https://metacpan.org/pod/Dancer::Request#is_post .

Saya tidak yakin apakah ini solusi yang sangat elegan, tapi menurut saya ini akan berhasil.

person Shlomi Fish    schedule 29.03.2014

arrow_upward
1
arrow_downward

Berikut pendapat lain mengenai masalah ini, berdasarkan pengalaman:

Karena Dancer belum memiliki kesempatan untuk mengurai parameter input Anda saat hook 'sebelum' dijalankan, Anda mungkin tidak memiliki cara yang konsisten untuk membaca kredensial autentikasi Anda, jika aplikasi Anda mengizinkannya disediakan dalam berbagai cara.

Khususnya, jika Anda menggunakan parameter input untuk meneruskan nonce guna mencegah serangan CSRF (yang tentunya harus Anda pertimbangkan!), Anda tidak akan memiliki cara yang konsisten untuk mendapatkan nonce tersebut. Anda dapat melakukan penguraian parameter mini sendiri di dalam 'sebelum', tetapi itu juga bisa berantakan.

Saya mengalami masalah ini ketika saya mengerjakan sebuah aplikasi beberapa waktu lalu, dan ingat harus menambahkan fungsi otentikasi boilerplate yang ditakuti ke setiap rute PUT/POST/DELETE. Kemudian, jika Anda melakukan itu, memeriksa request->is_post menjadi tidak relevan karena Anda sudah memutuskan apakah akan menempatkan fungsi otentikasi boilerplate dalam rute.

person yahermann    schedule 30.03.2014

arrow_upward
-1
arrow_downward

Saya belum mencobanya, tetapi mungkin saja untuk menangani tindakan prasyarat di kelas dasar Route Anda, lalu meneruskannya setelah berhasil. Ini akan membiarkan paket spesifik Anda menangani permintaan seperti biasa setelah kelas dasar Anda memverifikasi otentikasi.

Suatu tindakan dapat memilih untuk tidak melayani permintaan saat ini dan meminta Dancer memproses permintaan tersebut dengan rute pencocokan berikutnya. Hal ini dilakukan dengan kata kunci pass, seperti pada contoh berikut

get '/say/:word' => sub {
return pass if (params->{word} =~ /^\d+$/);
"I say a word: ".params->{word};
};

get '/say/:number' => sub {
    "I say a number: ".params->{number};
};
person MadHacker    schedule 24.05.2015