نسخه:

اعتبار سنجی

معرفی

لاراول چندین روش مختلف برای اعتبارسنجی داده های ورودی برنامه شما ارائه می دهد. به‌طور پیش‌فرض، کلاس کنترل‌کننده پایه لاراول از یک ValidatesRequests ویژگی استفاده می‌کند که روشی مناسب برای اعتبارسنجی درخواست‌های HTTP ورودی با انواع قوانین اعتبارسنجی قدرتمند ارائه می‌دهد.

شروع سریع اعتبارسنجی

برای آشنایی با ویژگی های قدرتمند اعتبارسنجی لاراول، اجازه دهید به یک مثال کامل از اعتبارسنجی یک فرم و نمایش پیام های خطا به کاربر نگاه کنیم.

تعریف مسیرها

ابتدا فرض می کنیم مسیرهای زیر را در فایل خود تعریف کرده ایم routes/web.php : 

Route::get('post/create', 'PostController@create');
 
Route::post('post', 'PostController@store');

مسیر GET فرمی را برای کاربر نمایش می دهد تا یک پست وبلاگ جدید ایجاد کند، در حالی که POST مسیر پست وبلاگ جدید را در پایگاه داده ذخیره می کند.

ایجاد کنترلر

در مرحله بعد، بیایید نگاهی به یک کنترلر ساده بیندازیم که این مسیرها را کنترل می کند. store فعلاً روش را خالی می گذاریم : 

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
use Illuminate\Http\Request;
 
class PostController extends Controller
{
    /**
     * Show the form to create a new blog post.
     *
     * @return Response
     */
    public function create()
    {
        return view('post.create');
    }
 
    /**
     * Store a new blog post.
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        // Validate and store the blog post...
    }
}

نوشتن منطق اعتبارسنجی

store اکنون ما آماده هستیم تا روش خود را با منطق تأیید اعتبار پست وبلاگ جدید پر کنیم . برای این کار از validate روش ارائه شده توسط شی استفاده می کنیم Illuminate\Http\Request . اگر قوانین اعتبارسنجی تصویب شوند، کد شما به طور عادی اجرا می شود. با این حال، اگر اعتبار سنجی ناموفق باشد، یک استثنا ایجاد می شود و پاسخ خطای مناسب به طور خودکار برای کاربر ارسال می شود. در مورد درخواست HTTP سنتی، یک پاسخ تغییر مسیر ایجاد می شود، در حالی که یک پاسخ JSON برای درخواست های AJAX ارسال می شود.

برای درک بهتر روش validate ، اجازه دهید دوباره به store روش پرش کنیم: 

/**
 * Store a new blog post.
 *
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request)
{
    $validatedData = $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);
 
    // The blog post is valid...
}

همانطور که می بینید، قوانین اعتبارسنجی مورد نظر را به validate متد منتقل می کنیم. مجدداً، اگر اعتبارسنجی ناموفق باشد، پاسخ مناسب به طور خودکار ایجاد می شود. اگر اعتبار سنجی بگذرد، کنترل کننده ما به اجرای عادی خود ادامه می دهد.

از طرف دیگر، قوانین اعتبارسنجی ممکن است به‌عنوان آرایه‌هایی از قوانین به جای یک | رشته محدود شده مشخص شوند: 

$validatedData = $request->validate([
    'title' => ['required', 'unique:posts', 'max:255'],
    'body' => ['required'],
]);

اگر می‌خواهید کیسه خطا را مشخص کنید که پیام‌های خطا باید در آن قرار گیرند، می‌توانید از validateWithBag روش زیر استفاده کنید: 

$request->validateWithBag('blog', [
    'title' => ['required', 'unique:posts', 'max:255'],
    'body' => ['required'],
]);

توقف در اولین شکست اعتبارسنجی

گاهی اوقات ممکن است بخواهید اجرای قوانین اعتبارسنجی روی یک ویژگی را پس از اولین شکست اعتبارسنجی متوقف کنید. برای انجام این کار، bail قانون را به ویژگی اختصاص دهید: 

$request->validate([
    'title' => 'bail|required|unique:posts|max:255',
    'body' => 'required',
]);

در این مثال، اگر unique قانون مربوط به title ویژگی ناموفق باشد، max قانون بررسی نخواهد شد. قوانین به ترتیبی که تخصیص داده شده اند تأیید می شوند.

نکته ای در مورد ویژگی های تودرتو

اگر درخواست HTTP شما حاوی پارامترهای "تودرتو" است، می توانید آنها را در قوانین اعتبارسنجی خود با استفاده از نحو "نقطه" مشخص کنید: 

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'author.name' => 'required',
    'author.description' => 'required',
]);

نمایش خطاهای اعتبارسنجی

بنابراین، اگر پارامترهای درخواست ورودی از قوانین اعتبار سنجی داده شده عبور نکنند، چه؟ همانطور که قبلا ذکر شد، لاراول به طور خودکار کاربر را به مکان قبلی خود هدایت می کند. علاوه بر این، تمام خطاهای اعتبارسنجی به طور خودکار به جلسه فلش می شود .

مجدداً، توجه داشته باشید که ما مجبور نیستیم پیام های خطا را به صراحت به نمای GET مسیر خود متصل کنیم. این به این دلیل است که لاراول خطاهای موجود در داده های جلسه را بررسی می کند و در صورت در دسترس بودن آنها را به طور خودکار به view متصل می کند. متغیر $errors نمونه ای از Illuminate\Support\MessageBag . برای اطلاعات بیشتر در مورد کار با این شی، مستندات آن را بررسی کنید .

متغیر توسط میان‌افزار که توسط گروه میان‌افزار ارائه می‌شود $errors به view محدود می‌شود . هنگامی که این میان افزار اعمال می شود، یک متغیر همیشه در نماهای شما در دسترس خواهد بود ، به شما این امکان را می دهد که به راحتی فرض کنید متغیر همیشه تعریف شده است و می توان با خیال راحت از آن استفاده کرد. Illuminate\View\Middleware\ShareErrorsFromSession web $errors $errors

بنابراین، در مثال ما، زمانی که اعتبارسنجی ناموفق باشد، کاربر به create روش کنترل‌کننده ما هدایت می‌شود و به ما امکان می‌دهد پیام‌های خطا را در نمای نمایش دهیم: 

<!-- /resources/views/post/create.blade.php -->
 
<h1>Create Post</h1>
 
@if ($errors->any())
    <div class="alert alert-danger">
        <ul>
            @foreach ($errors->all() as $error)
                <li>{{ $error }}</li>
            @endforeach
        </ul>
    </div>
@endif
 
<!-- Create Post Form -->

بخشنامه @error _

همچنین می‌توانید از دستورالعمل @error Blade برای بررسی سریع وجود پیام‌های خطای اعتبارسنجی برای یک ویژگی خاص استفاده کنید. در یک @error دستورالعمل، می توانید $message متغیر را برای نمایش پیام خطا تکرار کنید: 

<!-- /resources/views/post/create.blade.php -->
 
<label for="title">Post Title</label>
 
<input id="title" type="text" class="@error('title') is-invalid @enderror">
 
@error('title')
    <div class="alert alert-danger">{{ $message }}</div>
@enderror

یادداشتی در مورد فیلدهای اختیاری

به طور پیش فرض، لاراول شامل میان افزار TrimStrings و ConvertEmptyStringsToNull میان افزار در پشته میان افزار جهانی برنامه شما می شود. این میان افزارها در پشته توسط App\Http\Kernel کلاس فهرست شده اند. به همین دلیل، اغلب نیاز دارید که فیلدهای درخواستی "اختیاری" خود را علامت گذاری کنید، به گونه ای nullable که گویی نمی خواهید اعتباردهنده null مقادیر را نامعتبر در نظر بگیرد. مثلا: 

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
    'publish_at' => 'nullable|date',
]);

در این مثال، ما مشخص می‌کنیم که این publish_at فیلد ممکن است null یک نمایش تاریخ معتبر یا معتبر باشد. اگر nullable تعدیل کننده به تعریف قانون اضافه نشود، اعتباردهنده null تاریخ نامعتبر را در نظر می گیرد.

درخواست ها و اعتبارسنجی AJAX

در این مثال، ما از یک فرم سنتی برای ارسال داده به برنامه استفاده کردیم. با این حال، بسیاری از برنامه ها از درخواست های AJAX استفاده می کنند. هنگام استفاده از validate روش در طول درخواست AJAX، لاراول پاسخ تغییر مسیر ایجاد نمی کند. در عوض، لاراول یک پاسخ JSON حاوی تمام خطاهای اعتبارسنجی تولید می کند. این پاسخ JSON با کد وضعیت HTTP 422 ارسال خواهد شد.

اعتبار درخواست فرم

ایجاد درخواست های فرم

برای سناریوهای اعتبارسنجی پیچیده تر، ممکن است بخواهید یک "درخواست فرم" ایجاد کنید. درخواست‌های فرم، کلاس‌های درخواست سفارشی هستند که حاوی منطق اعتبارسنجی هستند. برای ایجاد کلاس درخواست فرم، از make:request دستور Artisan CLI استفاده کنید: 

php artisan make:request StoreBlogPost

کلاس تولید شده در app/Http/Requests دایرکتوری قرار می گیرد. اگر این دایرکتوری وجود نداشته باشد، هنگام اجرای make:request دستور ایجاد می شود. بیایید چند قانون اعتبارسنجی به rules روش اضافه کنیم: 

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

rules می توانید هر وابستگی مورد نیاز خود را در امضای روش تایپ کنید . آنها به طور خودکار از طریق ظرف سرویس لاراول حل می شوند .

بنابراین، قوانین اعتبارسنجی چگونه ارزیابی می شوند؟ تنها کاری که باید انجام دهید این است که درخواست را در روش کنترلر خود تایپ کنید. درخواست فرم ورودی قبل از فراخوانی متد کنترلر تایید می شود، به این معنی که نیازی نیست کنترل کننده خود را با هیچ منطق اعتبارسنجی درهم و برهم کنید: 

/**
 * Store the incoming blog post.
 *
 * @param  StoreBlogPost  $request
 * @return Response
 */
public function store(StoreBlogPost $request)
{
    // The incoming request is valid...
 
    // Retrieve the validated input data...
    $validated = $request->validated();
}

اگر اعتبارسنجی ناموفق باشد، یک پاسخ تغییر مسیر برای ارسال کاربر به مکان قبلی خود ایجاد می شود. خطاها نیز به جلسه فلش می شوند تا برای نمایش در دسترس باشند. اگر درخواست یک درخواست AJAX بود، یک پاسخ HTTP با کد وضعیت 422 شامل نمایش JSON از خطاهای اعتبار سنجی به کاربر بازگردانده می شود.

اضافه کردن After Hooks به فرم درخواست ها

اگر می‌خواهید یک قلاب «بعد» به درخواست فرم اضافه کنید، می‌توانید از این withValidator روش استفاده کنید. این روش اعتبارسنج کاملاً ساخته شده را دریافت می‌کند و به شما امکان می‌دهد تا قبل از ارزیابی قوانین اعتبارسنجی، هر یک از روش‌های آن را فراخوانی کنید: 

/**
 * Configure the validator instance.
 *
 * @param  \Illuminate\Validation\Validator  $validator
 * @return void
 */
public function withValidator($validator)
{
    $validator->after(function ($validator) {
        if ($this->somethingElseIsInvalid()) {
            $validator->errors()->add('field', 'Something is wrong with this field!');
        }
    });
}

مجوز درخواست های فرم

کلاس درخواست فرم نیز حاوی یک authorize متد است. در این روش، می‌توانید بررسی کنید که آیا کاربر احراز هویت شده واقعاً اختیار به‌روزرسانی یک منبع داده شده را دارد یا خیر. برای مثال، می‌توانید تعیین کنید که آیا کاربر واقعاً صاحب نظر وبلاگی است که می‌خواهد آن را به‌روزرسانی کند: 

/**
 * Determine if the user is authorized to make this request.
 *
 * @return bool
 */
public function authorize()
{
    $comment = Comment::find($this->route('comment'));
 
    return $comment && $this->user()->can('update', $comment);
}

از آنجایی که تمام درخواست‌های فرم کلاس درخواست پایه لاراول را گسترش می‌دهند، ممکن است از این user روش برای دسترسی به کاربر تأیید شده فعلی استفاده کنیم. همچنین به فراخوانی route متد در مثال بالا توجه کنید. این روش به شما امکان دسترسی به پارامترهای URI تعریف شده در مسیر فراخوانی شده را می دهد، مانند {comment} پارامتر در مثال زیر: 

Route::post('comment/{comment}');

اگر authorize روش برگردد false ، یک پاسخ HTTP با کد وضعیت 403 به طور خودکار برگردانده می شود و روش کنترل کننده شما اجرا نمی شود.

اگر قصد دارید منطق مجوز را در قسمت دیگری از برنامه خود داشته باشید، true از authorize روش برگردید: 

/**
 * Determine if the user is authorized to make this request.
 *
 * @return bool
 */
public function authorize()
{
    return true;
}

authorize می توانید هر وابستگی مورد نیاز خود را در امضای روش تایپ کنید . آنها به طور خودکار از طریق ظرف سرویس لاراول حل می شوند .

سفارشی کردن پیام های خطا

می‌توانید پیام‌های خطای مورد استفاده در درخواست فرم را با نادیده گرفتن messages روش سفارشی کنید. این متد باید یک آرایه از جفت‌های ویژگی/قانون و پیام‌های خطای مربوط به آن‌ها را برگرداند: 

/**
 * Get the error messages for the defined validation rules.
 *
 * @return array
 */
public function messages()
{
    return [
        'title.required' => 'A title is required',
        'body.required'  => 'A message is required',
    ];
}

سفارشی کردن ویژگی های اعتبارسنجی

اگر می‌خواهید :attribute بخشی از پیام تأیید اعتبار شما با نام ویژگی سفارشی جایگزین شود، می‌توانید نام‌های سفارشی را با لغو attributes روش تعیین کنید. این متد باید آرایه ای از جفت های ویژگی / نام را برگرداند: 

/**
 * Get custom attributes for validator errors.
 *
 * @return array
 */
public function attributes()
{
    return [
        'email' => 'email address',
    ];
}

ورودی را برای اعتبارسنجی آماده کنید

اگر قبل از اعمال قوانین اعتبارسنجی خود نیاز به پاکسازی هر گونه داده از درخواست دارید، می توانید از prepareForValidation روش زیر استفاده کنید: 

use Illuminate\Support\Str;
 
/**
 * Prepare the data for validation.
 *
 * @return void
 */
protected function prepareForValidation()
{
    $this->merge([
        'slug' => Str::slug($this->slug),
    ]);
}

ایجاد اعتبار سنجی دستی

اگر نمی‌خواهید از این validate روش در درخواست استفاده کنید، می‌توانید یک نمونه اعتبارسنجی به صورت دستی با استفاده از Validator نما ایجاد کنید . روش make روی نما یک نمونه اعتبارسنجی جدید ایجاد می کند: 

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;
 
class PostController extends Controller
{
    /**
     * Store a new blog post.
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ]);
 
        if ($validator->fails()) {
            return redirect('post/create')
                        ->withErrors($validator)
                        ->withInput();
        }
 
        // Store the blog post...
    }
}

اولین آرگومان ارسال شده به make متد، داده های تحت اعتبارسنجی است. آرگومان دوم قوانین اعتبارسنجی است که باید روی داده ها اعمال شود.

پس از بررسی عدم تأیید اعتبار درخواست، می توانید از withErrors روش فلش کردن پیام های خطا به جلسه استفاده کنید. هنگام استفاده از این روش، $errors متغیر به طور خودکار پس از تغییر مسیر با نماهای شما به اشتراک گذاشته می شود و به شما این امکان را می دهد که به راحتی آنها را به کاربر نمایش دهید. این withErrors روش یک اعتبار سنجی، یک MessageBag یا یک PHP را می پذیرد array .

تغییر مسیر خودکار

اگر می خواهید یک نمونه اعتبار سنجی به صورت دستی ایجاد کنید اما همچنان از تغییر مسیر خودکار ارائه شده توسط validate متد درخواست استفاده کنید، می توانید این validate روش را در یک نمونه اعتبارسنجی موجود فراخوانی کنید. اگر اعتبارسنجی ناموفق باشد، کاربر به طور خودکار هدایت می شود یا در صورت درخواست AJAX، یک پاسخ JSON برگردانده می شود: 

Validator::make($request->all(), [
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
])->validate();

به نام کیسه های خطا

اگر چندین فرم در یک صفحه دارید، ممکن است بخواهید MessageBag خطاها را نام ببرید و به شما امکان می دهد پیام های خطا را برای یک فرم خاص بازیابی کنید. یک نام را به عنوان آرگومان دوم به withErrors : 

return redirect('register')
            ->withErrors($validator, 'login');

سپس می توانید به MessageBag نمونه نامگذاری شده از $errors متغیر دسترسی پیدا کنید: 

{{ $errors->login->first('email') }}

پس از اعتبارسنجی هوک

اعتباردهنده همچنین به شما امکان می‌دهد تا پس از تکمیل اعتبارسنجی، تماس‌های برگشتی را ضمیمه کنید. این به شما امکان می دهد تا به راحتی اعتبار سنجی بیشتری انجام دهید و حتی پیام های خطای بیشتری را به مجموعه پیام اضافه کنید. برای شروع، after از روش یک نمونه اعتبار سنجی استفاده کنید: 

$validator = Validator::make(...);
 
$validator->after(function ($validator) {
    if ($this->somethingElseIsInvalid()) {
        $validator->errors()->add('field', 'Something is wrong with this field!');
    }
});
 
if ($validator->fails()) {
    //
}

کار با پیام های خطا

پس از فراخوانی errors متد بر روی یک Validator نمونه، یک نمونه دریافت خواهید کرد Illuminate\Support\MessageBag که دارای انواع روش های راحت برای کار با پیام های خطا است. متغیری $errors که به طور خودکار در دسترس همه نماها قرار می گیرد نیز نمونه ای از MessageBag کلاس است.

بازیابی اولین پیام خطا برای یک فیلد

برای بازیابی اولین پیام خطا برای یک فیلد مشخص، از first روش زیر استفاده کنید: 

$errors = $validator->errors();
 
echo $errors->first('email');

بازیابی همه پیام های خطا برای یک فیلد

اگر نیاز به بازیابی آرایه ای از همه پیام ها برای یک فیلد خاص دارید، از get روش زیر استفاده کنید: 

foreach ($errors->get('email') as $message) {
    //
}

اگر یک فیلد فرم آرایه را تأیید می‌کنید، می‌توانید تمام پیام‌های هر یک از عناصر آرایه را با استفاده از کاراکتر بازیابی کنید * : 

foreach ($errors->get('attachments.*') as $message) {
    //
}

بازیابی همه پیام های خطا برای همه فیلدها

برای بازیابی آرایه ای از همه پیام ها برای همه فیلدها، از all روش زیر استفاده کنید: 

foreach ($errors->all() as $message) {
    //
}

تعیین اینکه آیا پیام برای یک فیلد وجود دارد یا خیر

این has روش ممکن است برای تعیین اینکه آیا هر گونه پیام خطایی برای یک فیلد مشخص وجود دارد یا خیر استفاده شود: 

if ($errors->has('email')) {
    //
}

پیام های خطای سفارشی

در صورت نیاز، می‌توانید از پیام‌های خطای سفارشی برای اعتبارسنجی به جای پیش‌فرض‌ها استفاده کنید. راه های مختلفی برای تعیین پیام های سفارشی وجود دارد. ابتدا می توانید پیام های سفارشی را به عنوان آرگومان سوم به Validator::make متد ارسال کنید: 

$messages = [
    'required' => 'The :attribute field is required.',
];
 
$validator = Validator::make($input, $rules, $messages);

در این مثال، :attribute مکان نگهدار با نام واقعی فیلد تحت اعتبار سنجی جایگزین می شود. همچنین می‌توانید از متغیرهای دیگری در پیام‌های اعتبارسنجی استفاده کنید. مثلا: 

$messages = [
    'same'    => 'The :attribute and :other must match.',
    'size'    => 'The :attribute must be exactly :size.',
    'between' => 'The :attribute value :input is not between :min - :max.',
    'in'      => 'The :attribute must be one of the following types: :values',
];

تعیین یک پیام سفارشی برای یک ویژگی مشخص

گاهی اوقات ممکن است بخواهید یک پیام خطای سفارشی را فقط برای یک فیلد خاص مشخص کنید. می توانید این کار را با استفاده از نماد "نقطه" انجام دهید. ابتدا نام خصیصه و به دنبال آن قانون را مشخص کنید: 

$messages = [
    'email.required' => 'We need to know your e-mail address!',
];

تعیین پیام های سفارشی در فایل های زبان

در بیشتر موارد، شما احتمالاً پیام‌های سفارشی خود را به جای ارسال مستقیم به فایل زبان، در یک فایل زبان مشخص می‌کنید Validator . برای انجام این کار، پیام های خود را به custom آرایه در resources/lang/xx/validation.php فایل زبان اضافه کنید. 

'custom' => [
    'email' => [
        'required' => 'We need to know your e-mail address!',
    ],
],

تعیین ویژگی های سفارشی در فایل های زبان

اگر می‌خواهید :attribute بخشی از پیام تأیید اعتبار شما با نام ویژگی سفارشی جایگزین شود، می‌توانید نام سفارشی را در آرایه فایل زبان attributes خود مشخص کنید: resources/lang/xx/validation.php 

'attributes' => [
    'email' => 'email address',
],

تعیین مقادیر سفارشی در فایل های زبان

گاهی اوقات ممکن است لازم باشد :value بخشی از پیام تأیید اعتبار خود را با یک نمایش سفارشی از مقدار جایگزین کنید. به عنوان مثال، قاعده زیر را در نظر بگیرید که مشخص می‌کند در صورتی که payment_type مقدار آن برابر است با شماره کارت اعتباری مورد نیاز است cc : 

$request->validate([
    'credit_card_number' => 'required_if:payment_type,cc'
]);

اگر این قانون اعتبار سنجی ناموفق باشد، پیام خطای زیر را ایجاد می کند: 

The credit card number field is required when payment type is cc.

به جای نمایش cc به عنوان مقدار نوع پرداخت، می توانید با تعریف یک آرایه ، یک نمایش ارزش سفارشی را در validation فایل زبان خود مشخص کنید: values 

'values' => [
    'payment_type' => [
        'cc' => 'credit card'
    ],
],

حال اگر قانون اعتبارسنجی ناموفق باشد، پیام زیر را تولید می کند: 

The credit card number field is required when payment type is credit card.

قوانین اعتبار سنجی موجود

در زیر لیستی از تمام قوانین اعتبارسنجی موجود و عملکرد آنها آمده است:

پذیرفته شده URL فعال بعد از (تاریخ) بعد یا برابر (تاریخ) آلفا خط آلفا عدد آلفا آرایه وثیقه قبل از (تاریخ) قبل یا برابر (تاریخ) بین بولی تایید شده تاریخ تاریخ برابر است فرمت تاریخ ناهمسان ارقام ارقام بین ابعاد (فایل های تصویری) متمایز پست الکترونیک به پایان می رسد با Exclude If استثناء شود مگر اینکه موجود است (پایگاه داده) فایل پر شده است بزرگتر از بزرگتر یا مساوی فایل تصویری) که در در آرایه عدد صحیح آدرس آی پی JSON کمتر از کمتر یا برابر حداکثر انواع MIME نوع MIME بر اساس پسوند فایل حداقل نه در Regex نیست باطل شدنی عددی کلمه عبور حاضر عبارت منظم ضروری مورد نیاز اگر مورد نیاز مگر اینکه مورد نیاز با مورد نیاز با همه مورد نیاز بدون مورد نیاز بدون همه یکسان اندازه گاهی شروع می شود با رشته منطقه زمانی منحصر به فرد (پایگاه داده) URL UUID

پذیرفته شده

فیلد مورد تایید باید بله ، در ، 1 یا درست باشد . این برای تأیید پذیرش «شرایط خدمات» مفید است.

فعال_url

فیلد تحت اعتبارسنجی باید یک رکورد معتبر A یا AAAA مطابق dns_get_record تابع PHP داشته باشد. نام میزبان URL ارائه شده با استفاده از parse_url تابع PHP قبل از ارسال به dns_get_record .

بعد از: تاریخ

فیلد مورد تأیید باید مقداری پس از تاریخ معین باشد. تاریخ ها به تابع PHP منتقل می شوند strtotime : 

'start_date' => 'required|date|after:tomorrow'

به جای ارسال رشته تاریخ برای ارزیابی strtotime ، می توانید فیلد دیگری را برای مقایسه با تاریخ تعیین کنید: 

'finish_date' => 'required|date|after:start_date'

after_or_equal: تاریخ

فیلد مورد تأیید باید مقداری بعد از تاریخ داده شده یا برابر با آن باشد. برای اطلاعات بیشتر به قانون بعد مراجعه کنید .

آلفا

فیلد مورد تأیید باید کاملاً حروف الفبا باشد.

alpha_dash

فیلد تحت اعتبارسنجی ممکن است دارای نویسه‌های الف-عددی و همچنین خط تیره و زیرخط باشد.

alpha_num

فیلد مورد تأیید باید کاملاً نویسه‌های الفا عددی باشد.

آرایه

فیلد مورد تایید باید PHP باشد array .

وثیقه

اجرای قوانین اعتبارسنجی را پس از اولین شکست اعتبارسنجی متوقف کنید.

قبل از: تاریخ

فیلد تحت اعتبارسنجی باید مقداری قبل از تاریخ معین باشد. تاریخ ها به تابع PHP منتقل می شوند strtotime . علاوه بر این، مانند after قانون، نام یک فیلد دیگر تحت اعتبارسنجی ممکن است به عنوان مقدار ارائه شود date .

before_or_equal: تاریخ

فیلد مورد تأیید باید مقداری قبل یا برابر با تاریخ داده شده باشد. تاریخ ها به تابع PHP منتقل می شوند strtotime . علاوه بر این، مانند after قانون، نام یک فیلد دیگر تحت اعتبارسنجی ممکن است به عنوان مقدار ارائه شود date .

بین: حداقل ، حداکثر

فیلد تحت اعتبارسنجی باید دارای اندازه ای بین حداقل و حداکثر باشد . رشته‌ها، اعداد، آرایه‌ها و فایل‌ها به همان شیوه size قانون ارزیابی می‌شوند.

بولی

فیلد تحت اعتبارسنجی باید بتواند به صورت بولی فرستاده شود. ورودی پذیرفته شده عبارتند از true , false , 1 , 0 , "1" و "0" .

تایید شده

فیلد تحت اعتبارسنجی باید دارای یک فیلد منطبق با foo_confirmation . به عنوان مثال، اگر فیلد تحت اعتبارسنجی است password ، یک password_confirmation فیلد مطابق باید در ورودی وجود داشته باشد.

تاریخ

فیلد تحت اعتبار باید یک تاریخ معتبر و غیر نسبی مطابق تابع strtotime PHP باشد.

date_equals: تاریخ

فیلد مورد تایید باید برابر با تاریخ معین باشد. تاریخ ها به تابع PHP منتقل می شوند strtotime .

date_format: قالب

فیلد مورد تأیید باید با قالب داده شده مطابقت داشته باشد . شما باید از یکی date یا date_format در زمان اعتبارسنجی یک فیلد استفاده کنید، نه از هر دو. این قانون اعتبارسنجی از تمام فرمت های پشتیبانی شده توسط کلاس DateTime PHP پشتیبانی می کند .

متفاوت: میدانی

فیلد تحت اعتبارسنجی باید مقداری متفاوت از فیلد داشته باشد .

ارقام: ارزش

فیلد مورد تأیید باید عددی باشد و باید دارای طول دقیق باشد .

ارقام_بین: حداقل ، حداکثر

فیلد مورد تایید باید عددی باشد و باید بین حداقل و حداکثر طول داشته باشد .

ابعاد

فایل تحت اعتبارسنجی باید تصویری باشد که با محدودیت‌های ابعاد مشخص شده توسط پارامترهای قانون مطابقت داشته باشد: 

'avatar' => 'dimensions:min_width=100,min_height=200'

محدودیت های موجود عبارتند از: حداقل عرض ، حداکثر_عرض ، حداقل_ارتفاع ، حداکثر_ارتفاع ، عرض ، ارتفاع ، نسبت .

یک محدودیت نسبت باید به صورت تقسیم عرض بر ارتفاع نشان داده شود. این را می توان با عبارتی مانند 3/2 یا float مانند 1.5 : 

'avatar' => 'dimensions:ratio=3/2'

از آنجایی که این قانون به چندین آرگومان نیاز دارد، می توانید از Rule::dimensions روش برای ساخت روان قانون استفاده کنید: 

use Illuminate\Validation\Rule;
 
Validator::make($data, [
    'avatar' => [
        'required',
        Rule::dimensions()->maxWidth(1000)->maxHeight(500)->ratio(3 / 2),
    ],
]);

متمایز

هنگام کار با آرایه ها، فیلد تحت اعتبارسنجی نباید مقادیر تکراری داشته باشد. 

'foo.*.id' => 'distinct'

پست الکترونیک

فیلد مورد تأیید باید به عنوان یک آدرس ایمیل قالب بندی شود. در زیر سرپوش، این قانون اعتبارسنجی از egulias/email-validator بسته برای اعتبارسنجی آدرس ایمیل استفاده می کند. به طور پیش فرض RFCValidation اعتبار سنج اعمال می شود، اما می توانید سبک های اعتبار سنجی دیگر را نیز اعمال کنید: 

'email' => 'email:rfc,dns'

مثال بالا اعتبار سنجی RFCValidation و را اعمال می کند DNSCheckValidation . در اینجا فهرست کاملی از سبک‌های اعتبارسنجی وجود دارد که می‌توانید اعمال کنید:

  • rfc : RFCValidation
  • strict : NoRFCWarningsValidation
  • dns : DNSCheckValidation
  • spoof : SpoofCheckValidation
  • filter : FilterEmailValidation

اعتبار filter سنجی که از تابع PHP filter_var در زیر هود استفاده می کند، با لاراول ارسال می شود و رفتار لاراول قبل از 5.8 است. اعتبار سنجی dns و به پسوند spoof PHP نیاز دارند intl .

پایان_با: فو ، بار ،...

فیلد تحت اعتبارسنجی باید با یکی از مقادیر داده شده خاتمه یابد.

exclude_if: یک فیلد دیگر ، مقدار

اگر فیلد دیگری برابر با مقدار باشد ، فیلد تحت اعتبارسنجی از داده‌های درخواستی که توسط روش‌های validate و بازگردانده می‌شود، حذف می‌شود . validated

exclude_less: otherfield , value

فیلد تحت اعتبارسنجی از داده های درخواستی که توسط متدهای validate و بازگردانده می شود حذف می شود validated مگر اینکه فیلد فیلد دیگری با مقدار برابر باشد .

وجود دارد: جدول ، ستون

فیلد تحت اعتبار باید در جدول پایگاه داده مشخص وجود داشته باشد.

قانون اساسی استفاده از موجود 

'state' => 'exists:states'

اگر column گزینه مشخص نشده باشد، از نام فیلد استفاده می شود.

تعیین نام ستون سفارشی 

'state' => 'exists:states,abbreviation'

گاهی اوقات، ممکن است لازم باشد اتصال پایگاه داده خاصی را برای استفاده برای exists پرس و جو تعیین کنید. شما می توانید این کار را با اضافه کردن نام اتصال به نام جدول با استفاده از نحو "نقطه" انجام دهید: 

'email' => 'exists:connection.staff,email'

به جای تعیین مستقیم نام جدول، می توانید مدل Eloquent را که باید برای تعیین نام جدول استفاده شود را مشخص کنید: 

'user_id' => 'exists:App\User,id'

اگر می خواهید پرس و جوی اجرا شده توسط قانون اعتبارسنجی را سفارشی کنید، می توانید از Rule کلاس برای تعریف روان قانون استفاده کنید. در این مثال، قوانین اعتبارسنجی را به‌جای استفاده از | کاراکتر برای محدود کردن آنها، به‌عنوان یک آرایه مشخص می‌کنیم : 

use Illuminate\Validation\Rule;
 
Validator::make($data, [
    'email' => [
        'required',
        Rule::exists('staff')->where(function ($query) {
            $query->where('account_id', 1);
        }),
    ],
]);

فایل

فیلد تحت تأیید باید یک فایل با موفقیت آپلود شده باشد.

پر شده است

فیلد تحت اعتبارسنجی در صورت وجود نباید خالی باشد.

gt: میدان

فیلد مورد تایید باید بزرگتر از فیلد داده شده باشد . دو فیلد باید از یک نوع باشند. رشته‌ها، اعداد، آرایه‌ها و فایل‌ها با استفاده از قراردادهای مشابه به عنوان size قانون ارزیابی می‌شوند.

gte: میدان

فیلد مورد تأیید باید بزرگتر یا مساوی با فیلد داده شده باشد . دو فیلد باید از یک نوع باشند. رشته‌ها، اعداد، آرایه‌ها و فایل‌ها با استفاده از قراردادهای مشابه به عنوان size قانون ارزیابی می‌شوند.

تصویر

فایل تحت اعتبارسنجی باید یک تصویر (jpeg، png، bmp، gif، svg یا webp) باشد.

در: فو ، بار ، ...

فیلد مورد تایید باید در لیست مقادیر داده شده گنجانده شود. از آنجایی که این قانون اغلب شما را به implode یک آرایه نیاز دارد، این Rule::in روش ممکن است برای ساخت روان قانون استفاده شود: 

use Illuminate\Validation\Rule;
 
Validator::make($data, [
    'zones' => [
        'required',
        Rule::in(['first-zone', 'second-zone']),
    ],
]);

in_array: otherfield .*

فیلد تحت اعتبار باید در مقادیر فیلد دیگری وجود داشته باشد.

عدد صحیح

فیلد مورد تایید باید یک عدد صحیح باشد.

این قانون اعتبار سنجی تأیید نمی کند که ورودی از نوع متغیر "integer" باشد، فقط اینکه ورودی یک رشته یا مقدار عددی است که حاوی یک عدد صحیح است.

آی پی

فیلد مورد تایید باید یک آدرس IP باشد.

ipv4

فیلد مورد تایید باید یک آدرس IPv4 باشد.

ipv6

فیلد مورد تایید باید یک آدرس IPv6 باشد.

json

فیلد تحت اعتبارسنجی باید یک رشته JSON معتبر باشد.

lt: میدان

فیلد مورد تأیید باید کمتر از فیلد داده شده باشد . دو فیلد باید از یک نوع باشند. رشته‌ها، اعداد، آرایه‌ها و فایل‌ها با استفاده از قراردادهای مشابه به عنوان size قانون ارزیابی می‌شوند.

lte: میدان

فیلد مورد تایید باید کمتر یا مساوی با فیلد داده شده باشد . دو فیلد باید از یک نوع باشند. رشته‌ها، اعداد، آرایه‌ها و فایل‌ها با استفاده از قراردادهای مشابه به عنوان size قانون ارزیابی می‌شوند.

حداکثر: ارزش

فیلد تحت اعتبارسنجی باید کمتر یا مساوی یک مقدار حداکثر باشد . رشته‌ها، اعداد، آرایه‌ها و فایل‌ها به همان شیوه size قانون ارزیابی می‌شوند.

mimetypes: متن/ساده ،...

فایل تحت اعتبارسنجی باید با یکی از انواع MIME داده شده مطابقت داشته باشد: 

'video' => 'mimetypes:video/avi,video/mpeg,video/quicktime'

برای تعیین نوع MIME فایل آپلود شده، محتویات فایل خوانده می شود و چارچوب سعی می کند نوع MIME را حدس بزند، که ممکن است با نوع MIME ارائه شده توسط مشتری متفاوت باشد.

میم: فو ، بار ،...

فایل تحت اعتبارسنجی باید دارای یک نوع MIME مطابق با یکی از پسوندهای فهرست شده باشد.

استفاده اساسی از قانون MIME 

'photo' => 'mimes:jpeg,bmp,png'

حتی اگر فقط باید پسوندها را مشخص کنید، این قانون در واقع با خواندن محتویات فایل و حدس زدن نوع MIME آن، نسبت به نوع MIME فایل اعتبارسنجی می کند.

فهرست کامل انواع MIME و پسوندهای مربوط به آنها را می توان در مکان زیر یافت: https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types

دقیقه: ارزش

فیلد تحت اعتبارسنجی باید دارای حداقل مقدار باشد . رشته‌ها، اعداد، آرایه‌ها و فایل‌ها به همان شیوه size قانون ارزیابی می‌شوند.

not_in: فو ، بار ،...

فیلد تحت اعتبارسنجی نباید در لیست مقادیر داده شده گنجانده شود. این Rule::notIn روش ممکن است برای ساخت روان قانون استفاده شود: 

use Illuminate\Validation\Rule;
 
Validator::make($data, [
    'toppings' => [
        'required',
        Rule::notIn(['sprinkles', 'cherries']),
    ],
]);

not_regex: الگو

فیلد تحت اعتبارسنجی نباید با عبارت منظم داده شده مطابقت داشته باشد.

در داخل، این قانون از تابع PHP استفاده می کند preg_match . الگوی مشخص شده باید از همان قالب بندی مورد نیاز پیروی کند preg_match و بنابراین شامل جداکننده های معتبر نیز باشد. مثلا: 'email' => 'not_regex:/^.+$/i' .

توجه: هنگام استفاده از الگوهای regex / not_regex ، ممکن است لازم باشد به جای استفاده از جداکننده لوله، قوانین را در یک آرایه مشخص کنید، به خصوص اگر عبارت منظم حاوی یک کاراکتر لوله باشد.

باطل شدنی

فیلد تحت اعتبارسنجی ممکن است باشد null . این به ویژه هنگام اعتبارسنجی اولیه مانند رشته ها و اعداد صحیح که می توانند حاوی null مقادیر باشند مفید است.

عددی

فیلد مورد تایید باید عددی باشد.

کلمه عبور

فیلد تحت تأیید باید با رمز عبور کاربر تأیید شده مطابقت داشته باشد. می توانید با استفاده از پارامتر اول قانون، یک محافظ احراز هویت را مشخص کنید: 

'password' => 'password:api'

حاضر

فیلد مورد تایید باید در داده های ورودی وجود داشته باشد اما می تواند خالی باشد.

regex: الگو

فیلد تحت اعتبارسنجی باید با عبارت منظم داده شده مطابقت داشته باشد.

در داخل، این قانون از تابع PHP استفاده می کند preg_match . الگوی مشخص شده باید از همان قالب بندی مورد نیاز پیروی کند preg_match و بنابراین شامل جداکننده های معتبر نیز باشد. مثلا: 'email' => 'regex:/^.+@.+$/i' .

توجه: هنگام استفاده از الگوهای regex / not_regex ، ممکن است لازم باشد به جای استفاده از جداکننده لوله، قوانین را در یک آرایه مشخص کنید، به خصوص اگر عبارت منظم حاوی یک کاراکتر لوله باشد.

ضروری

فیلد مورد تایید باید در داده های ورودی وجود داشته باشد و خالی نباشد. اگر یکی از شرایط زیر درست باشد یک فیلد "خالی" در نظر گرفته می شود:

  • ارزش است null .
  • مقدار یک رشته خالی است.
  • مقدار یک آرایه خالی یا Countable شی خالی است.
  • مقدار یک فایل آپلود شده بدون مسیر است.

require_if: یک فیلد دیگر ، مقدار ،...

اگر فیلد دیگری برابر با هر مقداری باشد ، فیلد تحت اعتبارسنجی باید وجود داشته باشد و خالی نباشد .

اگر می خواهید شرط پیچیده تری برای required_if قاعده بسازید، می توانید از Rule::requiredIf روش استفاده کنید. این روش یک بولی یا یک بسته را می پذیرد. هنگامی که یک Close تصویب می شود، بسته شدن باید برگردد true یا false نشان دهد که آیا فیلد تحت اعتبارسنجی مورد نیاز است: 

use Illuminate\Validation\Rule;
 
Validator::make($request->all(), [
    'role_id' => Rule::requiredIf($request->user()->is_admin),
]);
 
Validator::make($request->all(), [
    'role_id' => Rule::requiredIf(function () use ($request) {
        return $request->user()->is_admin;
    }),
]);

مورد نیاز_ مگر اینکه: یک فیلد دیگر ، مقدار ،...

فیلد تحت اعتبارسنجی باید موجود باشد و خالی نباشد مگر اینکه فیلد دیگری با هر مقداری برابر باشد .

مورد نیاز_با: فو ، بار ،...

فیلد تحت اعتبارسنجی باید وجود داشته باشد و تنها در صورت وجود هر یک از فیلدهای مشخص شده دیگر خالی نباشد.

مورد نیاز_با_همه: فو ، بار ،...

فیلد تحت اعتبارسنجی باید وجود داشته باشد و تنها در صورتی خالی نباشد که تمام فیلدهای مشخص شده دیگر وجود داشته باشد.

الزامی_بدون: فو ، بار ،...

فیلد تحت اعتبارسنجی باید وجود داشته باشد و فقط زمانی که هیچ یک از فیلدهای مشخص شده دیگر وجود ندارد خالی نباشد.

مورد نیاز_بدون_همه: فو ، بار ،...

فیلد تحت اعتبارسنجی باید وجود داشته باشد و تنها زمانی که تمام فیلدهای مشخص شده دیگر وجود ندارند خالی نباشد.

همان: میدان

فیلد داده شده باید با فیلد تحت اعتبارسنجی مطابقت داشته باشد.

اندازه: ارزش

فیلد تحت اعتبارسنجی باید اندازه ای مطابق با مقدار داده شده داشته باشد . برای داده های رشته ای، مقدار مربوط به تعداد کاراکترها است. برای داده های عددی، مقدار مربوط به یک مقدار صحیح داده شده است (ویژگی باید قانون numeric یا را نیز داشته باشد integer ). برای یک آرایه، اندازه با count آرایه مطابقت دارد. برای فایل ها، اندازه با حجم فایل بر حسب کیلوبایت مطابقت دارد. بیایید به چند نمونه نگاه کنیم: 

// Validate that a string is exactly 12 characters long...
'title' => 'size:12';
 
// Validate that a provided integer equals 10...
'seats' => 'integer|size:10';
 
// Validate that an array has exactly 5 elements...
'tags' => 'array|size:5';
 
// Validate that an uploaded file is exactly 512 kilobytes...
'image' => 'file|size:512';

شروع_با: فو ، بار ،...

فیلد تحت اعتبارسنجی باید با یکی از مقادیر داده شده شروع شود.

رشته

فیلد مورد تایید باید یک رشته باشد. اگر می‌خواهید اجازه دهید فیلد نیز باشد null ، باید nullable قانون را به فیلد اختصاص دهید.

منطقه زمانی

فیلد تحت اعتبار باید یک شناسه منطقه زمانی معتبر مطابق تابع timezone_identifiers_list PHP باشد.

منحصر به فرد: جدول ، ستون ، به جز ، idColumn

فیلد تحت اعتبارسنجی نباید در جدول پایگاه داده داده شده وجود داشته باشد.

تعیین یک جدول سفارشی / نام ستون:

به جای تعیین مستقیم نام جدول، می توانید مدل Eloquent را که باید برای تعیین نام جدول استفاده شود را مشخص کنید: 

'email' => 'unique:App\User,email_address'

این column گزینه ممکن است برای تعیین ستون پایگاه داده مربوط به فیلد استفاده شود. اگر column گزینه مشخص نشده باشد، از نام فیلد استفاده می شود. 

'email' => 'unique:users,email_address'

اتصال به پایگاه داده سفارشی

گاهی اوقات، ممکن است لازم باشد یک اتصال سفارشی برای درخواست های پایگاه داده ایجاد شده توسط Validator تنظیم کنید. همانطور که در بالا مشاهده شد، تنظیم unique:users به عنوان یک قانون اعتبارسنجی از اتصال پایگاه داده پیش فرض برای پرس و جو از پایگاه داده استفاده می کند. برای لغو این، اتصال و نام جدول را با استفاده از نحو "نقطه" مشخص کنید: 

'email' => 'unique:connection.users,email_address'

اجبار یک قانون منحصر به فرد برای نادیده گرفتن شناسه داده شده:

گاهی اوقات، ممکن است بخواهید در طول بررسی منحصر به فرد، یک شناسه داده شده را نادیده بگیرید. به عنوان مثال، یک صفحه "به روز رسانی نمایه" را در نظر بگیرید که شامل نام، آدرس ایمیل و مکان کاربر است. احتمالاً می خواهید تأیید کنید که آدرس ایمیل منحصر به فرد است. با این حال، اگر کاربر فقط فیلد نام و نه فیلد ایمیل را تغییر دهد، نمی‌خواهید یک خطای اعتبارسنجی ایجاد شود زیرا کاربر قبلاً مالک آدرس ایمیل است.

برای دستور اعتباردهنده نادیده گرفتن شناسه کاربر، از Rule کلاس برای تعریف روان قانون استفاده می کنیم. در این مثال، به جای استفاده از | کاراکتر برای محدود کردن قوانین، قوانین اعتبارسنجی را به عنوان یک آرایه نیز مشخص می کنیم : 

use Illuminate\Validation\Rule;
 
Validator::make($data, [
    'email' => [
        'required',
        Rule::unique('users')->ignore($user->id),
    ],
]);

شما هرگز نباید ورودی درخواست کنترل شده توسط کاربر را به ignore روش ارسال کنید. درعوض، فقط باید یک شناسه منحصر به فرد تولید شده از سیستم مانند شناسه افزایش خودکار یا UUID را از یک نمونه مدل Eloquent ارسال کنید. در غیر این صورت، برنامه شما در برابر حمله تزریق SQL آسیب پذیر خواهد بود.

به جای انتقال مقدار کلید مدل به ignore متد، می‌توانید کل نمونه مدل را ارسال کنید. لاراول به طور خودکار کلید را از مدل استخراج می کند: 

Rule::unique('users')->ignore($user)

اگر جدول شما از نام ستون کلید اصلی به غیر از نام استفاده می کند id ، می توانید نام ستون را هنگام فراخوانی ignore متد مشخص کنید: 

Rule::unique('users')->ignore($user->id, 'user_id')

به‌طور پیش‌فرض، این unique قانون منحصربه‌فرد بودن ستونی را که با نام ویژگی تأیید شده مطابقت دارد بررسی می‌کند. با این حال، می توانید نام ستون دیگری را به عنوان آرگومان دوم به unique متد ارسال کنید: 

Rule::unique('users', 'email_address')->ignore($user->id),

اضافه کردن بند های اضافی Where:

همچنین می توانید با سفارشی کردن پرس و جو با استفاده از where روش، محدودیت های اضافی پرس و جو را مشخص کنید. به عنوان مثال، اجازه دهید یک محدودیت اضافه کنیم که این را تأیید می account_id کند 1 : 

'email' => Rule::unique('users')->where(function ($query) {
    return $query->where('account_id', 1);
})

آدرس اینترنتی

فیلد تحت تأیید باید یک URL معتبر باشد.

uuid

فیلد تحت اعتبارسنجی باید یک شناسه منحصر به فرد جهانی (UUID) معتبر RFC 4122 (نسخه 1، 3، 4 یا 5) باشد.

اضافه کردن قوانین مشروط

اعتبار سنجی هنگام وجود

در برخی شرایط، ممکن است بخواهید فقط در صورتی که آن فیلد در آرایه ورودی وجود داشته باشد، بررسی های اعتبار سنجی را بر روی یک فیلد اجرا کنید. برای انجام سریع این کار، sometimes قانون را به لیست قوانین خود اضافه کنید: 

$v = Validator::make($data, [
    'email' => 'sometimes|required|email',
]);

در مثال بالا، email فیلد فقط در صورتی تایید می شود که در آرایه موجود باشد $data .

اگر می‌خواهید فیلدی را تأیید کنید که همیشه باید وجود داشته باشد اما ممکن است خالی باشد، این یادداشت را در زمینه‌های اختیاری بررسی کنید.

اعتبار سنجی مشروط پیچیده

گاهی اوقات ممکن است بخواهید قوانین اعتبارسنجی را بر اساس منطق شرطی پیچیده تر اضافه کنید. به عنوان مثال، شما ممکن است بخواهید یک فیلد معین را تنها در صورتی بخواهید که فیلد دیگری دارای مقدار بیشتر از 100 باشد. اضافه کردن این قوانین اعتبار سنجی نباید دردسرساز باشد. ابتدا یک نمونه با قوانین استاتیک Validator خود ایجاد کنید که هرگز تغییر نمی کند: 

$v = Validator::make($data, [
    'email' => 'required|email',
    'games' => 'required|numeric',
]);

بیایید فرض کنیم برنامه وب ما برای کلکسیونرهای بازی است. اگر یک کلکسیونر بازی در برنامه ما ثبت نام کند و بیش از 100 بازی داشته باشد، از او می خواهیم توضیح دهد که چرا صاحب این همه بازی است. به عنوان مثال، شاید آنها یک فروشگاه فروش مجدد بازی دارند، یا شاید آنها فقط از جمع آوری لذت می برند. برای اضافه کردن مشروط این نیاز، می‌توانیم از sometimes روش روی Validator نمونه استفاده کنیم. 

$v->sometimes('reason', 'required|max:500', function ($input) {
    return $input->games >= 100;
});

اولین آرگومان ارسال شده به sometimes متد، نام فیلدی است که به صورت مشروط اعتبارسنجی می کنیم. آرگومان دوم قوانینی است که می خواهیم اضافه کنیم. اگر Closure آرگومان تصویب شده به عنوان سومین آرگومان برگردد true ، قوانین اضافه خواهند شد. این روش ساختن اعتبارسنجی های شرطی پیچیده را آسان می کند. حتی می توانید اعتبار سنجی شرطی را برای چندین فیلد به طور همزمان اضافه کنید: 

$v->sometimes(['reason', 'cost'], 'required', function ($input) {
    return $input->games >= 100;
});

پارامتری $input که به شما ارسال می شود Closure نمونه ای از آن خواهد بود Illuminate\Support\Fluent و ممکن است برای دسترسی به ورودی و فایل های شما استفاده شود.

اعتبار سنجی آرایه ها

اعتبار سنجی فیلدهای ورودی فرم مبتنی بر آرایه نباید دردسرساز باشد. می‌توانید از «نقطه‌گذاری» برای اعتبارسنجی ویژگی‌های درون یک آرایه استفاده کنید. برای مثال، اگر درخواست HTTP ورودی حاوی یک photos[profile] فیلد باشد، می‌توانید آن را به این صورت تأیید کنید: 

$validator = Validator::make($request->all(), [
    'photos.profile' => 'required|image',
]);

همچنین می توانید هر عنصر یک آرایه را اعتبارسنجی کنید. به عنوان مثال، برای تأیید اینکه هر ایمیل در یک فیلد ورودی آرایه خاص منحصر به فرد است، می توانید کارهای زیر را انجام دهید: 

$validator = Validator::make($request->all(), [
    'person.*.email' => 'email|unique:users',
    'person.*.first_name' => 'required_with:person.*.last_name',
]);

به همین ترتیب، می‌توانید * هنگام تعیین پیام‌های تأیید اعتبار در فایل‌های زبان خود از این کاراکتر استفاده کنید، و استفاده از یک پیام تأیید اعتبار برای فیلدهای مبتنی بر آرایه را آسان می‌کند: 

'custom' => [
    'person.*.email' => [
        'unique' => 'Each person must have a unique e-mail address',
    ]
],

قوانین اعتبار سنجی سفارشی

استفاده از Rule Objects

لاراول انواع مختلفی از قوانین اعتبار سنجی مفید را ارائه می دهد. با این حال، ممکن است بخواهید برخی از موارد خود را مشخص کنید. یکی از روش‌های ثبت قوانین اعتبارسنجی سفارشی، استفاده از اشیاء قوانین است. برای ایجاد یک شی قانون جدید، می توانید از make:rule دستور Artisan استفاده کنید. بیایید از این دستور برای ایجاد قاعده ای استفاده کنیم که بزرگ بودن یک رشته را تأیید می کند. لاراول قانون جدید را در app/Rules دایرکتوری قرار می دهد: 

php artisan make:rule Uppercase

هنگامی که قانون ایجاد شد، ما آماده هستیم تا رفتار آن را تعریف کنیم. یک شی قانون شامل دو روش است: passes و message . متد passes مقدار مشخصه و نام را دریافت می کند و باید بسته به معتبر بودن یا نبودن مقدار مشخصه true برگردد . false این message روش باید پیغام خطای اعتبارسنجی را برگرداند که باید در صورت شکست اعتبارسنجی استفاده شود: 

<?php
 
namespace App\Rules;
 
use Illuminate\Contracts\Validation\Rule;
 
class Uppercase implements Rule
{
    /**
     * Determine if the validation rule passes.
     *
     * @param  string  $attribute
     * @param  mixed  $value
     * @return bool
     */
    public function passes($attribute, $value)
    {
        return strtoupper($value) === $value;
    }
 
    /**
     * Get the validation error message.
     *
     * @return string
     */
    public function message()
    {
        return 'The :attribute must be uppercase.';
    }
}

اگر می‌خواهید پیام خطای فایل‌های ترجمه خود را برگردانید، می‌توانید trans از روش خود با Helper تماس بگیرید: message 

/**
 * Get the validation error message.
 *
 * @return string
 */
public function message()
{
    return trans('validation.uppercase');
}

هنگامی که قانون تعریف شد، می‌توانید با ارسال نمونه‌ای از شی قانون با سایر قوانین اعتبارسنجی خود، آن را به اعتبارسنجی متصل کنید: 

use App\Rules\Uppercase;
 
$request->validate([
    'name' => ['required', 'string', new Uppercase],
]);

استفاده از بسته ها

اگر فقط یک بار به عملکرد یک قانون سفارشی در سراسر برنامه خود نیاز دارید، می توانید به جای یک شی قانون از Closure استفاده کنید. بسته شدن نام مشخصه، مقدار مشخصه و یک $fail فراخوانی را دریافت می کند که در صورت عدم موفقیت اعتبار باید فراخوانی شود: 

$validator = Validator::make($request->all(), [
    'title' => [
        'required',
        'max:255',
        function ($attribute, $value, $fail) {
            if ($value === 'foo') {
                $fail($attribute.' is invalid.');
            }
        },
    ],
]);

استفاده از برنامه های افزودنی

روش دیگر ثبت قوانین اعتبار سنجی سفارشی استفاده از extend روش روی Validator نما است . بیایید از این روش در یک ارائه دهنده خدمات برای ثبت یک قانون اعتبار سنجی سفارشی استفاده کنیم: 

<?php
 
namespace App\Providers;
 
use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Validator;
 
class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }
 
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        Validator::extend('foo', function ($attribute, $value, $parameters, $validator) {
            return $value == 'foo';
        });
    }
}

اعتبار سنجی سفارشی Closure چهار آرگومان دریافت می کند: نام مورد $attribute تایید شده، $value صفت، آرایه ای از $parameters ارسال شده به قانون، و Validator نمونه.

همچنین می توانید یک کلاس و متد را extend به جای Closure به متد ارسال کنید: 

Validator::extend('foo', 'FooValidator@validate');

تعریف پیام خطا

همچنین باید یک پیام خطا برای قانون سفارشی خود تعریف کنید. می توانید این کار را با استفاده از یک آرایه پیام سفارشی درون خطی یا با افزودن یک ورودی در فایل زبان اعتبارسنجی انجام دهید. این پیام باید در سطح اول آرایه قرار گیرد، نه در آرایه custom ، که فقط برای پیام های خطای مشخصه است: 

"foo" => "Your input was invalid!",
 
"accepted" => "The :attribute must be accepted.",
 
// The rest of the validation error messages...

هنگام ایجاد یک قانون اعتبارسنجی سفارشی، گاهی اوقات ممکن است نیاز داشته باشید که جایگزین‌های جای‌بان سفارشی را برای پیام‌های خطا تعریف کنید. می‌توانید این کار را با ایجاد یک اعتبارسنجی سفارشی همانطور که در بالا توضیح داده شد و سپس فراخوانی روش replacer روی Validator نما انجام دهید. می توانید این کار را در boot روش ارائه دهنده خدمات انجام دهید : 

/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
    Validator::extend(...);
 
    Validator::replacer('foo', function ($message, $attribute, $rule, $parameters) {
        return str_replace(...);
    });
}

پسوندهای ضمنی

به‌طور پیش‌فرض، زمانی که مشخصه‌ای که اعتبارسنجی می‌شود وجود نداشته باشد یا حاوی یک رشته خالی باشد، قوانین اعتبارسنجی عادی، از جمله پسوندهای سفارشی، اجرا نمی‌شوند. به عنوان مثال، unique قانون در برابر یک رشته خالی اجرا نمی شود: 

$rules = ['name' => 'unique:users,name'];
 
$input = ['name' => ''];
 
Validator::make($input, $rules)->passes(); // true

برای اجرای یک قانون حتی زمانی که یک ویژگی خالی است، این قانون باید به این معنی باشد که ویژگی مورد نیاز است. برای ایجاد چنین پسوند "ضمنی"، از Validator::extendImplicit() روش استفاده کنید: 

Validator::extendImplicit('foo', function ($attribute, $value, $parameters, $validator) {
    return $value == 'foo';
});

پسوند "ضمنی" فقط به این معنی است که ویژگی مورد نیاز است. اینکه آیا واقعاً یک ویژگی گم شده یا خالی را باطل می کند به شما بستگی دارد.

اشیاء قانون ضمنی

اگر می‌خواهید زمانی که یک ویژگی خالی است، یک شیء قانون اجرا شود، باید اینترفیس را پیاده‌سازی کنید Illuminate\Contracts\Validation\ImplicitRule . این رابط به عنوان یک "واسط نشانگر" برای اعتبار سنج عمل می کند. بنابراین، شامل هیچ روشی نیست که شما برای پیاده سازی آن نیاز دارید.