Artikel ini akan meneroka pengesahan data dan mengapa ia begitu penting. Kami akan membandingkan pengesahan klien dengan pengesahan sisi pelayan dan menjelaskan mengapa pengesahan sisi klien tidak boleh dipercayai.
Kami kemudiannya akan memperkenalkan beberapa peraturan pengesahan mudah yang saya gunakan dalam aplikasi Laravel saya. Akhirnya, kita akan belajar bagaimana untuk membuat peraturan pengesahan kita sendiri dan menguji mereka untuk memastikan ia berfungsi seperti yang diharapkan.
Apakah pengesahan data?
Biasanya, apabila mengesahkan data dalam aplikasi web, jika data tidak sah, anda perlu mengembalikan mesej ralat kepada pengguna.
Ini membantu mencegah kelemahan keselamatan, rasuah data dan meningkatkan ketepatan data. Oleh itu, kami akan terus memproses permintaan hanya jika data itu sah.
Ingat, anda tidak boleh mempercayai sebarang data dari pengguna (sekurang -kurangnya sebelum anda mengesahkannya!).
Mengapa pengesahan data penting?
# meningkatkan keselamatan
# mencegah penyimpanan data yang salah
Untuk memberi contoh lain, katakan anda sedang membina aplikasi web yang membolehkan pengguna mengundi pada pengundian. Pengundian hanya boleh diundi antara masa
masa dan AppModelsPoll
yang dinyatakan pada model opens_at
. Apa yang berlaku jika seseorang secara tidak sengaja menetapkan masa closes_at
sebelum masa closes_at
ketika membuat pengundian? Bergantung pada bagaimana anda mengendalikan ini dalam aplikasi anda, ini boleh menyebabkan pelbagai masalah. opens_at
# pastikan perintah artisan dimasukkan dengan betul
pengesahan pelanggan dan pengesahan pelayan
Pengesahan pelanggan adalah pengesahan yang dilakukan dalam penyemak imbas sebelum menghantar data ke pelayan. Ia boleh dilaksanakan menggunakan JavaScript atau atribut HTML.
Contohnya, kita boleh menambah beberapa pengesahan mudah ke medan nombor dalam HTML untuk memastikan nombor yang dimasukkan oleh pengguna adalah antara 1 dan 10:
<input type="number" min="1" max="10" required>
type="number"
min="1"
max="10"
required
Ini sangat bermanfaat untuk membimbing pengguna dan meningkatkan pengalaman pengguna keseluruhan aplikasi. Tetapi itu hanya perlu dipertimbangkan: panduan. Anda tidak sepatutnya bergantung semata -mata pada pengesahan klien sebagai satu -satunya bentuk pengesahan dalam permohonan anda.
Jika seseorang membuka alat pemaju dalam penyemak imbas mereka, mereka dapat dengan mudah mengeluarkan dan memintas pengesahan klien yang telah anda tetapkan.
Di samping itu, adalah penting untuk diingat bahawa apabila pengguna berniat jahat cuba menyerang aplikasi anda, mereka biasanya akan menggunakan skrip automatik untuk menghantar permintaan terus ke pelayan anda. Ini bermakna bahawa pengesahan pelanggan yang telah anda tetapkan akan dilangkau.
# Pengesahan sisi pelayan
Oleh kerana pengesahan adalah pada pelayan anda, pengguna tidak dapat mengubahnya, ini adalah satu -satunya cara untuk memastikan bahawa data yang dihantar ke pelayan adalah sah.
Oleh itu, pastikan anda sentiasa mengaktifkan pengesahan sisi pelayan dalam aplikasi anda. Sebaik -baiknya, setiap bidang yang anda cuba baca dari permintaan harus disahkan sebelum cuba menggunakannya untuk melaksanakan logik perniagaan.
bagaimana Laravel mengendalikan pengesahan
Jika anda telah menggunakan Laravel untuk seketika, anda akan tahu bahawa Laravel mempunyai sistem pengesahan yang luar biasa yang dibina ke dalam rangka kerja. Oleh itu, sangat mudah untuk dimulakan dengan pengesahan dalam aplikasi anda.
Terdapat beberapa cara biasa untuk mengesahkan data di Laravel, tetapi kami akan meliputi dua cara yang paling biasa:
Untuk mengesahkan data secara manual (contohnya dalam kaedah pengawal), anda boleh menggunakan fasad IlluminateSupportFacadesValidator
dan panggil kaedah make
.
kita kemudian boleh lulus dua parameter ke make
kaedah:
data
- Data yang ingin kami sahkan rules
- peraturan yang ingin kami sahkan data berdasarkan Nota sampingan: Kaedah make
juga menerima dua parameter pilihan: messages
dan attributes
. Ini boleh digunakan untuk menyesuaikan mesej ralat yang dikembalikan kepada pengguna, tetapi kami tidak akan menutupnya dalam artikel ini.
mari kita lihat contoh di mana anda mungkin ingin mengesahkan dua bidang:
<input type="number" min="1" max="10" required>
Dalam contoh di atas, kita dapat melihat bahawa kita mengesahkan dua bidang: title
dan body
. Kami telah mengodkan nilai -nilai kedua -dua bidang ini untuk membuat contoh yang lebih jelas, tetapi dalam projek -projek sebenar anda biasanya mendapat bidang ini dari permintaan. Kami menyemak sama ada medan title
ditetapkan, adalah rentetan, dan mempunyai panjang maksimum 100 aksara. Kami juga menyemak sama ada medan description
ditetapkan, adalah rentetan, dan mempunyai panjang maksimum 250 aksara.
Selepas membuat validator, kita boleh memanggil kaedah pada contoh yang dikembalikan. Sebagai contoh, untuk memeriksa sama ada pengesahan gagal, kita boleh memanggil kaedah IlluminateValidationValidator
: fails
use Illuminate\Support\Facades\Validator; $validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] );
kaedah pada contoh pengesahan: validate
$validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] ); if ($validator->fails()) { // 一个或多个字段验证失败。 // 在此处进行处理... }
ini akan meningkatkan validate
. Laravel secara automatik akan mengendalikan pengecualian ini berdasarkan jenis permintaan yang dibuat (dengan mengandaikan bahawa anda tidak mengubah pengendalian pengecualian lalai dalam aplikasi anda). Jika permintaan itu adalah permintaan web, Laravel akan menggunakan ralat dalam sesi untuk mengarahkan pengguna kembali ke halaman sebelumnya untuk anda memaparkan. Sekiranya permintaan itu adalah permintaan API, Laravel mengembalikan respons IlluminateValidationValidationException
yang mengandungi perwakilan JSON ralat pengesahan seperti berikut: 422 Unprocessable Entity
Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] )->validate();
yang digunakan untuk menjalankan pemeriksaan kebenaran dan pengesahan pada permintaan masuk. IlluminateFoundationHttpFormRequest
mari kita lihat contoh mudah. Katakan kita mempunyai pengawal
AppHttpControllersUserController
<input type="number" min="1" max="10" required>
Dalam kaedah pengawal, kita dapat melihat bahawa kita menerima kelas permintaan AppHttpRequestsUsersStoreUserRequest
(yang akan kita perkenalkan kemudian) sebagai parameter kaedah. Ini akan menunjukkan kepada Laravel bahawa kami mahu menjalankan pengesahan secara automatik dalam kelas permintaan ini apabila kaedah ini dipanggil lebih banyak permintaan HTTP.
Kemudian, kami menggunakan kaedah validated
pada contoh permintaan dalam kaedah pengawal untuk mendapatkan data yang disahkan dari permintaan. Ini bermakna ia hanya akan mengembalikan data yang disahkan. Sebagai contoh, jika kita cuba menyimpan medan profile_picture
baru dalam pengawal, kita juga mesti menambahkannya ke kelas permintaan borang. Jika tidak, kaedah validated
tidak akan mengembalikannya, jadi $request->validated('profile_picture')
akan kembali null
.
mari kita lihat Kelas Permintaan Borang AppHttpRequestsUsersStoreUserRequest
:
use Illuminate\Support\Facades\Validator; $validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] );
kita dapat melihat bahawa kelas permintaan mengandungi dua kaedah:
authorize
: Kaedah ini digunakan untuk menentukan sama ada pengguna mempunyai hak untuk membuat permintaan. Jika kaedah kembali false
, tindak balas 403 Forbidden
dikembalikan kepada pengguna. Jika kaedah kembali true
, peraturan pengesahan akan dijalankan. rules
: Kaedah ini digunakan untuk menentukan peraturan pengesahan yang harus dijalankan atas permintaan. Kaedah ini harus mengembalikan pelbagai peraturan yang harus dijalankan atas permintaan. Dalam kaedah rules
, kami menyatakan bahawa medan name
mesti ditetapkan, mestilah rentetan, dan panjang maksimum mestilah 100 aksara. Kami juga menyatakan bahawa medan email
mesti ditetapkan, mestilah e -mel, dan mesti unik dalam jadual users
(pada lajur email
). Akhirnya, kami menyatakan bahawa medan password
mesti ditetapkan dan mesti lulus peraturan pengesahan kata laluan lalai yang telah kami tetapkan (kami akan menutup pengesahan kata laluan kemudian).
seperti yang anda lihat, ini adalah cara yang baik untuk memisahkan logik pengesahan dari logik pengawal, dan saya dapati ia menjadikan kod lebih mudah dibaca dan diselenggarakan.
Seperti yang telah saya sebutkan, sistem pengesahan Laravel sangat kuat dan dengan mudah boleh menambah pengesahan ke aplikasi anda.
Dalam bahagian ini, kami akan dengan cepat memperkenalkan beberapa peraturan pengesahan mudah yang saya suka, yang saya fikir kebanyakan pengguna akan mendapat berguna dalam aplikasi mereka.
Jika anda berminat untuk melihat semua peraturan yang terdapat di Laravel, anda boleh menemui mereka dalam dokumentasi Laravel: https://www.php.cn/link/45d5c43856059a4f97d43d6534be52d0
# Sahkan Arraymari kita lihat contoh bagaimana untuk mengesahkan array, dan kemudian kita akan membincangkan apa yang sedang dilakukan:
<input type="number" min="1" max="10" required>
Dalam contoh di atas, kita lulus pelbagai objek, masing -masing dengan medan name
dan email
.
Untuk pengesahan, kita mula -mula menentukan bahawa medan users
ditetapkan dan merupakan array. Kemudian, kami menyatakan bahawa setiap item array (menggunakan users.*
arah) adalah array yang mengandungi medan name
dan email
.
Kemudian, kami menyatakan bahawa medan name
(menggunakan users.*.name
arah) mesti ditetapkan, mestilah rentetan dan tidak boleh melebihi 100 aksara. Kami juga menyatakan bahawa medan email
(menggunakan users.*.email
arahan) mesti ditetapkan, mestilah e -mel, dan mesti unik pada lajur users
jadual email
.
Dengan dapat menggunakan *
wildcard dalam peraturan pengesahan, kami dapat dengan mudah mengesahkan array data dalam permohonan kami.
Laravel menyediakan beberapa peraturan pengesahan tarikh yang mudah yang boleh anda gunakan. Pertama, untuk mengesahkan bahawa medan adalah tarikh yang sah, anda boleh menggunakan date
peraturan:
use Illuminate\Support\Facades\Validator; $validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] );
Jika anda lebih suka menyemak sama ada tarikh dalam format tertentu, anda boleh menggunakan peraturan date_format
:
$validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] ); if ($validator->fails()) { // 一个或多个字段验证失败。 // 在此处进行处理... }
Anda mungkin perlu menyemak sama ada tarikh itu lebih awal atau lebih lambat daripada tarikh lain. Sebagai contoh, katakan permintaan anda mengandungi medan opens_at
dan closes_at
, dan anda ingin memastikan closes_at
lebih lewat daripada opens_at
dan opens_at
lebih lewat daripada atau sama dengan hari ini. Anda boleh menggunakan peraturan after
:
Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] )->validate();
Dalam contoh di atas, kita dapat melihat bahawa kita telah lulus today
sebagai parameter ke aturan opens_at
medan after
. Laravel akan cuba menukar rentetan ini ke dalam objek strtotime
yang sah menggunakan fungsi DateTime
dan membandingkannya dengan objek tersebut.
Untuk medan closes_at
, kami lulus opens_at
sebagai parameter kepada peraturan after_or_equal
. Laravel secara automatik akan mengesan bahawa ini adalah bidang lain yang disahkan dan membandingkan kedua -dua bidang antara satu sama lain.
Begitu juga, Laravel juga menyediakan before
dan before_or_equal
peraturan yang boleh anda gunakan untuk memeriksa sama ada tarikh lebih awal daripada tarikh lain:
{ "message": "The title field is required. (and 1 more error)", "errors": { "title": [ "The title field is required." ], "description": [ "The description field is required." ] } }
Sebagai pemaju web, tugas kami adalah untuk membantu pengguna selamat dalam talian. Salah satu cara yang boleh kita lakukan adalah untuk mempromosikan amalan kata laluan yang baik dalam aplikasi kami, seperti memerlukan kata laluan untuk panjang tertentu, mengandungi aksara tertentu, dll.
Laravel memudahkan kerja kami dengan menyediakan kelas IlluminateValidationRulesPassword
yang boleh kita gunakan untuk mengesahkan kata laluan.
Ia dilengkapi dengan beberapa kaedah yang boleh kita hubungkan bersama untuk membina peraturan pengesahan kata laluan yang kita mahu. Sebagai contoh, katakan kami mahu kata laluan pengguna memenuhi kriteria berikut:
pengesahan kami mungkin kelihatan seperti ini:
<input type="number" min="1" max="10" required>
Seperti yang ditunjukkan dalam contoh, kami menggunakan kaedah yang boleh dikaitkan untuk membina peraturan pengesahan kata laluan yang kami mahukan. Tetapi apa yang berlaku jika kita menggunakan peraturan ini di pelbagai tempat yang berbeza (mis., Daftar, menetapkan semula kata laluan, kemas kini kata laluan pada halaman akaun anda, dll.) Dan kita perlu mengubah pengesahan ini untuk menguatkuasakan sekurang -kurangnya 12 aksara? Kita perlu melangkah melalui segala -galanya di mana peraturan ini digunakan dan mengemas kini mereka.
Untuk memudahkan ini, Laravel membolehkan kami menentukan set peraturan pengesahan kata laluan yang boleh kami gunakan sepanjang aplikasi kami. Kami boleh menentukan satu set peraturan lalai dengan menggunakan kaedah AppProvidersAppServiceProvider
seperti ini dalam kaedah boot
kami: Password::defaults()
use Illuminate\Support\Facades\Validator; $validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] );
dalam peraturan pengesahan dan menggunakan peraturan yang kami tentukan dalam Password::defaults()
untuk: AppServiceProvider
$validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] ); if ($validator->fails()) { // 一个或多个字段验证失败。 // 在此处进行处理... }
Pada masa lalu, saya terpaksa menggunakan ungkapan biasa (saya akui saya tidak tahu banyak tentangnya) untuk mengesahkan bahawa warna adalah warna yang sah dalam format hex (mis.
untuk menggunakan: #FF00FF
hex_color
Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] )->validate();
Katakan anda ingin membenarkan pengguna memuat naik fail PDF (.pdf) atau Microsoft Word (.docx). Pengesahan mungkin kelihatan seperti ini:
Dalam contoh kod, kita dapat melihat bahawa kita mengesahkan jenis fail dan juga menetapkan beberapa had saiz fail minimum dan maksimum. Kami menggunakan kaedah
{ "message": "The title field is required. (and 1 more error)", "errors": { "title": [ "The title field is required." ], "description": [ "The description field is required." ] } }
Kaedah types
juga boleh menerima rentetan yang mengandungi akhiran lain yang menunjukkan unit saiz fail. Sebagai contoh, kita juga boleh menggunakan: min
max
10kb
10mb
10gb
Di samping itu, kita juga boleh menggunakan kaedah 10tb
<input type="number" min="1" max="10" required>
Dalam contoh di atas, kami mengesahkan bahawa fail itu adalah imej, menetapkan beberapa had saiz fail minimum dan maksimum, dan menetapkan beberapa saiz maksimum (500 x 500 piksel).
anda mungkin mahu mengambil pendekatan yang berbeza untuk memfailkan muat naik dalam aplikasi anda. Sebagai contoh, anda mungkin mahu memuat naik terus dari pelayar pengguna ke penyimpanan awan (mis. S3). Jika anda lebih suka melakukan ini, anda mungkin ingin menyemak fail muat naik saya dalam artikel Laravel menggunakan FilePond, yang menunjukkan kepada anda bagaimana untuk melakukan ini, kaedah pengesahan yang berbeza yang mungkin perlu anda ambil, dan bagaimana untuk mengujinya.
Satu lagi pemeriksaan biasa yang mungkin anda mahu lakukan ialah memastikan nilai wujud dalam pangkalan data.
Sebagai contoh, katakan anda mempunyai beberapa pengguna dalam aplikasi anda dan anda telah membuat laluan supaya anda boleh mengikatnya kepada pasukan. Oleh itu, dalam permintaan anda, anda mungkin perlu mengesahkan bahawa user_ids
yang diluluskan dalam permintaan wujud dalam jadual users
.
exists
Dalam contoh di atas, kami menyemak sama ada setiap ID yang diluluskan dalam array
use Illuminate\Support\Facades\Validator; $validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] );
. user_ids
users
Ini adalah cara yang baik untuk memastikan data yang anda gunakan adalah sah dan wujud dalam pangkalan data sebelum cuba menggunakannya. id
ke peraturan
untuk menapis lagi pertanyaan yang berjalan:
where
exists
Dalam contoh di atas, kami menyemak sama ada setiap ID yang diluluskan dalam array
$validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] ); if ($validator->fails()) { // 一个或多个字段验证失败。 // 在此处进行处理... }
, dan lajur user_ids
pengguna ditetapkan ke users
. Oleh itu, jika kita lulus ID pengguna yang tidak disahkan, pengesahan akan gagal. id
is_verified
# Sahkan keunikan bidang dalam pangkalan data true
exists
Sebagai contoh, katakan anda mempunyai jadual unique
dan anda ingin memastikan medan
: users
email
unique
Dalam contoh di atas, kami menyemak sama ada medan
Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] )->validate();
. email
users
yang mengandungi alamat e -mel pengguna cuba mengemaskini. Dalam kes ini, kita boleh menggunakan kaedah email
untuk mengabaikan ID pengguna semasa memeriksa keunikan:
users
Jika anda memilih untuk menggunakan kaedah ignore
, anda pasti akan membaca amaran ini dalam dokumentasi Laravel:
.
mungkin juga bahawa kadang -kadang anda mahu menambah klausa ignore
tambahan kepada peraturan . Anda mungkin perlu melakukan ini untuk memastikan alamat e -mel adalah unik kepada pasukan tertentu (yang bermaksud pengguna lain dalam pasukan yang berbeza boleh menggunakan e -mel yang sama). Anda boleh melakukan ini dengan lulus penutupan ke kaedah
unique
where
Buat Peraturan Pengesahan Anda Sendiri where
<input type="number" min="1" max="10" required>
Mari lihat bagaimana untuk membina peraturan pengesahan tersuai, cara menggunakannya, dan kemudian cara menulis ujian untuknya.
Untuk tujuan artikel ini, kami tidak begitu prihatin terhadap apa yang kami sahkan. Kami hanya ingin memahami struktur umum membuat peraturan pengesahan tersuai dan bagaimana untuk menguji mereka. Oleh itu, kami akan membuat peraturan mudah untuk memeriksa sama ada rentetan itu adalah palindrome.
Jika anda tidak tahu, palindrome adalah urutan perkataan, frasa, nombor, atau watak lain yang membaca perkara yang sama di arah ke hadapan dan terbalik. Sebagai contoh, "Racecar" adalah palindrome kerana jika anda membalikkan rentetan, ia masih "racecar". Dan "Laravel" bukanlah palindrome, kerana jika anda membalikkan rentetan itu akan menjadi "Levaral".
untuk memulakan, kami akan membuat peraturan pengesahan baru dengan menjalankan arahan berikut dalam laluan projek:
Ini harus membuat fail
baru untuk kami:
use Illuminate\Support\Facades\Validator; $validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] );
Laravel secara automatik akan memanggil kaedah App/Rules/Palindrome.php
apabila menjalankan peraturan. Kaedah ini menerima tiga parameter:
$validator = Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] ); if ($validator->fails()) { // 一个或多个字段验证失败。 // 在此处进行处理... }
validate
: Nama harta yang disahkan.
$attribute
$value
$fail
dengan mesej ralat. Ini akan menyebabkan bidang gagal mengesahkan. Jika pengesahan berlalu, peraturan itu tidak akan melakukan apa -apa dan kami boleh terus menggunakan permohonan kami. validate
Validator::make( data: [ 'title' => 'Blog Post', 'description' => 'Blog post description', ], rules: [ 'title' => ['required', 'string', 'max:100'], 'description' => ['required', 'string', 'max:250'], ] )->validate();
$fail
Walaupun ini adalah peraturan mudah yang kami buat untuk tujuan demonstrasi, saya harap ini akan memberi anda idea bagaimana untuk membina peraturan yang lebih kompleks untuk permohonan anda.
Sama seperti kod lain dalam aplikasi anda, adalah penting untuk menguji peraturan pengesahan anda untuk memastikan ia berfungsi seperti yang diharapkan. Jika tidak, anda mungkin mengambil risiko menggunakan peraturan yang tidak berfungsi seperti yang diharapkan.
Untuk memahami bagaimana untuk melakukan ini, mari kita lihat bagaimana untuk menguji peraturan palindrome yang kami buat di bahagian sebelumnya.
Untuk peraturan khusus ini, kami ingin menguji dua situasi:
Anda mungkin mempunyai lebih banyak situasi dalam peraturan yang lebih kompleks, tetapi untuk tujuan artikel ini, kami tetap mudah.
kami akan membuat fail ujian baru bernama tests/Unit/Rules
dalam direktori PalindromeTest.php
.
mari kita lihat fail ujian, dan kemudian kita akan membincangkan apa yang sedang dilakukan:
<input type="number" min="1" max="10" required>
Dalam fail ujian di atas, kami menentukan dua ujian: rule_passes_with_a_valid_value
dan rule_fails_with_an_invalid_value
.
Seperti nama ujian, ujian pertama memastikan bahawa peraturan itu berlalu apabila nilai adalah palindrome, dan ujian kedua memastikan bahawa peraturan gagal apabila nilai itu bukan palindrome.
Kami menggunakan atribut PHPUnitFrameworkAttributesDataProvider
untuk menyediakan senarai nilai yang sah dan tidak sah untuk ujian untuk ujian. Ini adalah cara yang baik untuk memastikan ujian anda kemas dan dapat menyemak pelbagai nilai dengan ujian yang sama. Sebagai contoh, jika seseorang menambah nilai yang sah baru kepada kaedah validValues
, ujian akan secara automatik berjalan terhadap nilai tersebut.
Dalam ujian rule_passes_with_a_valid_value
, kami menggunakan nilai yang sah untuk memanggil kaedah validate
pada peraturan. Kami lulus penutupan kepada parameter fail
(parameter ini dipanggil jika pengesahan dalaman peraturan gagal). Kami telah menyatakan bahawa jika penutupan dilaksanakan (iaitu, pengesahan gagal), ujian harus gagal. Jika kita sampai ke akhir ujian tanpa melaksanakan penutupan, maka kita tahu bahawa peraturan telah berlalu dan kita boleh menambah pernyataan mudah assertTrue(true)
untuk lulus ujian.
Dalam ujian rule_fails_with_an_invalid_value
, kita sama dengan yang pertama, tetapi kali ini kita lulus nilai yang tidak sah kepada peraturan. Kami telah menyatakan bahawa jika penutupan dilaksanakan (iaitu, pengesahan gagal), ujian harus lulus kerana kami mengharapkan penutupan itu dipanggil. Sekiranya kita sampai ke akhir ujian tanpa melaksanakan penutupan, tiada pernyataan dilaksanakan dan PHPUnit harus mencetuskan amaran untuk kita. Walau bagaimanapun, jika anda lebih suka memastikan bahawa ujian gagal lebih jelas daripada hanya memberikan kesilapan, anda mungkin perlu mengambil pendekatan yang sedikit berbeza untuk menulis ujian.
Dalam artikel ini, kita mengkaji apa pengesahan dan mengapa ia penting. Kami membandingkan pengesahan klien dengan pengesahan sisi pelayan dan meneroka mengapa pengesahan sisi klien tidak boleh digunakan sebagai satu-satunya bentuk pengesahan dalam aplikasi.
kami juga meliputi beberapa peraturan pengesahan yang mudah yang saya suka gunakan dalam aplikasi Laravel saya. Akhirnya, kami meneroka cara membuat peraturan pengesahan anda sendiri dan menguji mereka untuk memastikan ia berfungsi seperti yang diharapkan.
Semoga anda kini cukup yakin untuk mula menggunakan lebih banyak pengesahan untuk meningkatkan keselamatan dan kebolehpercayaan permohonan anda.
Atas ialah kandungan terperinci Panduan Terbaik untuk Pengesahan Laravel. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!