laravel 是網(wǎng)絡(luò)工匠的 php 框架。這有助于我們構(gòu)建強大的應(yīng)用程序和 api。很多人都知道有很多方法可以驗證 laravel 中的請求。處理請求驗證是任何應(yīng)用程序中非常重要的部分。laravel 有一些很好的功能，可以很好地處理這個問題。
入門
我們大多數(shù)人都熟悉在控制器中使用驗證器。這是處理傳入請求驗證的最常用方法。
以下是我們的驗證器的樣子 UserController
<?php namespace ApphttpControllersAPIv1Users; use AppHttpControllersController; use IlluminateHttpRequest; use IlluminateSupportFacadesValidator; use AppEntitiesModelsUser; class UserController extends Controller { public function store(Request $request) { // validate incoming request $validator = Validator::make($request->all(),?[ ???????????'email'?=>?'required|email|unique:users', ???????????'name'?=>?'required|string|max:50', ???????????'password'?=>?'required' ???????]); ???????if?($validator->fails())?{ ????????????Session::flash('error',?$validator->messages()->first()); ????????????return?redirect()->back()->withInput(); ???????} ???????//?finally?store?our?user ????} }
在控制器中驗證
在控制器中驗證傳入請求沒有任何問題，但這不是最好的方法，你的控制器看起來很亂。在我看來，這是不好的做法。控制器應(yīng)該只處理來自路由的一個處理請求并返回適當?shù)捻憫?yīng)。
在控制器中編寫驗證邏輯將打破單一責任原則。我們都知道需求會隨著時間的推移而變化，每次需求變更時，您的班級職責也會發(fā)生變化。因此，在單一班級中承擔很多責任使得管理變得非常困難。
Laravel 具有表單請求，一個包含驗證邏輯的單獨請求類。要創(chuàng)建一個，您可以在 Artisan 命令下使用。
php artisan make：請求 UserStoreRequest
這將創(chuàng)建新的 Request 類 appHttpRequestUserRequest
<?php namespace AppHttpRequests; use IlluminateFoundationHttpFormRequest; class UserStoreRequest extends FormRequest { /** * Determine if the user is authorized to make this request. * * @return bool */ public function authorize() { return true; } /** * Get the validation rules that apply to the request. * * @return array */ public function rules() { return [ 'email' =>?'required|email|unique:users', ????????????'name'?=>?'required|string|max:50', ????????????'password'?=>?'required' ????????]; ????} ?????/** ?????*?Custom?message?for?validation ?????* ?????*?@return?array ?????*/ ????public?function?messages() ????{ ????????return?[ ????????????'email.required'?=>?'Email?is?required!', ????????????'name.required'?=>?'Name?is?required!', ????????????'password.required'?=>?'Password?is?required!' ????????]; ????} }
Laravel Form Request 類有兩個默認方法 auth() 和 rules()。auth() 無論當前用戶是否被允許請求，您都可以在方法中執(zhí)行任何授權(quán)邏輯。在 rules() 方法中，您可以編寫所有驗證規(guī)則。還有一種方法 messages() 可以傳遞自己的驗證消息數(shù)組。
現(xiàn)在改變我們 UserController 使用我們 UserStoreRequest. 你可以輸入提示我們的請求類，它會在調(diào)用我們的控制器函數(shù)之前自動解析和驗證。
<?php namespace AppHttpControllersAPIv1Users; use AppHttpControllersController; use AppHttpRequestsUserStoreRequest; class UserController extends Controller { public function store(UserStoreRequest $request) { // Will return only validated data $validated = $request->validated(); ????} }
所以我們的控制器現(xiàn)在很纖薄，易于維護。現(xiàn)在我們的控制器不需要擔心任何驗證邏輯。我們有自己的驗證類，只有一個責任來處理驗證，讓控制器在那里工作。
如果驗證失敗，它會將用戶重定向到上一個位置并顯示錯誤。取決于您的請求類型錯誤消息將在會話中閃爍。如果請求是 ajax，則將返回帶有 422 狀態(tài)代碼的響應(yīng)，并返回 json 格式的錯誤。
回報
通過清理輸入來保持您的應(yīng)用程序和用戶的安全。在您的應(yīng)用程序中使用清潔劑，它將確保數(shù)據(jù)始終格式良好且一致。在許多情況下，由于愚蠢的格式錯誤，驗證失敗。
用戶輸入的移動電話號碼為 + 99-9999-999999 或 + 99-（9999） – （999999）。這是非常常見的錯誤，我們不能強迫我們的用戶再次重新輸入相同的細節(jié)。
其他一些例子是用戶輸入的電子郵件為 Foo@Bar.COM 或 FOO@Bar.com。或者輸入名字和姓氏，如 FOO **bAR 或 foo baR**
Sanitizer 包含在提供給驗證器之前以通用格式轉(zhuǎn)換和過濾數(shù)據(jù)的方法。
我正在使用 Waavi/Sanitizer 包含許多過濾器的包。
Waavi / 數(shù)據(jù)清洗
讓我們 BaseFormRequest 為 Form Request 創(chuàng)建抽象類，并 SanitizesInput 在這里使用 trait。
<?php namespace AppHttpRequests; use IlluminateContractsValidationValidator; use IlluminateFoundationHttpFormRequest; use IlluminateHttpExceptionsHttpResponseException; use IlluminateHttpJsonResponse; use WaaviSanitizerLaravelSanitizesInput; abstract class BaseFormRequest extends FormRequest { use ApiResponse, SanitizesInput; /** * For more sanitizer rule check https://github.com/Waavi/Sanitizer */ public function validateResolved() { { $this->sanitize(); ????????????parent::validateResolved(); ????????} ????} ????/** ?????*?Get?the?validation?rules?that?apply?to?the?request. ?????* ?????*?@return?array ?????*/ ????abstract?public?function?rules(); ????/** ?????*?Determine?if?the?user?is?authorized?to?make?this?request. ?????* ?????*?@return?bool ?????*/ ????abstract?public?function?authorize(); }
所以現(xiàn)在我們可以寫 UserStoreRequest 下面的內(nèi)容。從我們的基類擴展您的表單請求，因此我們不必在所有請求類中包含特征。
<?php namespace AppHttpRequests; class UserStoreRequest extends BaseFormRequest { /** * Determine if the user is authorized to make this request. * * @return bool */ public function authorize() { return true; } /** * Get the validation rules that apply to the request. * * @return array */ public function rules() { return [ 'email' =>?'required|email|unique:users', ????????????'name'?=>?'required|string|max:50', ????????????'password'?=>?'required' ????????]; ????} ????public?function?messages() ????{ ????????return?[ ????????????'email.required'?=>?'Email?is?required!', ????????????'name.required'?=>?'Name?is?required!', ????????????'password.required'?=>?'Password?is?required!' ????????]; ????} ????/** ?????*??Filters?to?be?applied?to?the?input. ?????* ?????*?@return?array ?????*/ ????public?function?filters() ????{ ????????return?[ ????????????'email'?=>?'trim|lowercase', ????????????'name'?=>?'trim|capitalize|escape' ????????]; ????} }
SanitizesInputtrait 提供了一種 filters() 在提供給驗證器之前格式化我們的請求數(shù)據(jù)的方法。filters() 方法返回有效過濾器的數(shù)組。在這里，我們將用戶電子郵件轉(zhuǎn)換為小寫并修剪相同的方式將名稱轉(zhuǎn)換為大寫并轉(zhuǎn)義任何 html 標記。
您可以從此處詳細了解可用的過濾器。
結(jié)論
首先，似乎沒有必要為所有人制作單獨的請求類。但是想象一下將所有驗證邏輯放在同一個控制器中。這就像是一場糟糕的噩夢 – 當它來管理你的代碼時，如果其他人必須管理它，那就更糟了？。
謝謝你的閱讀。
我想聽聽你對此的看法。如果您有任何問題或建議，請留下以下評論。
祝你有美好的一天。
更多Laravel相關(guān)技術(shù)文章，請訪問Laravel框架入門教程欄目進行學習！
