اعتبار سنجی

• معرفی
• شروع سریع اعتبارسنجی
  • تعریف مسیرها
  • ایجاد کنترلر
  • نوشتن منطق اعتبارسنجی
  • نمایش خطاهای اعتبارسنجی
  • جمعیت مجدد فرم ها
  • یادداشتی در مورد فیلدهای اختیاری
  • فرمت پاسخ خطای اعتبارسنجی
• اعتبار درخواست فرم
  • ایجاد درخواست های فرم
  • مجوز درخواست فرم
  • سفارشی کردن پیام های خطا
  • آماده سازی ورودی برای اعتبارسنجی
• ایجاد اعتبار سنجی دستی
  • تغییر مسیر خودکار
  • به نام کیسه های خطا
  • سفارشی کردن پیام های خطا
  • انجام اعتبار سنجی اضافی
• کار با ورودی معتبر
• کار با پیام های خطا
  • تعیین پیام های سفارشی در فایل های زبان
  • تعیین ویژگی ها در فایل های زبان
  • تعیین مقادیر در فایل های زبان
• قوانین اعتبار سنجی موجود
• اضافه کردن قوانین مشروط
• اعتبار سنجی آرایه ها
  • اعتبار سنجی ورودی آرایه تودرتو
  • فهرست ها و موقعیت های پیام خطا
• اعتبار سنجی فایل ها
• اعتبارسنجی رمزهای عبور
• قوانین اعتبار سنجی سفارشی
  • استفاده از Rule Objects
  • استفاده از بسته ها
  • قوانین ضمنی

معرفی

لاراول چندین روش مختلف برای اعتبارسنجی داده های ورودی برنامه شما ارائه می دهد. استفاده از validate روش موجود در تمام درخواست های HTTP دریافتی رایج ترین است . با این حال، ما سایر رویکردهای اعتبارسنجی را نیز مورد بحث قرار خواهیم داد.

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

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

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

تعریف مسیرها

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

use App\Http\Controllers\PostController;
 
Route::get('/post/create', [PostController::class, 'create']);
Route::post('/post', [PostController::class, 'store']);

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

ایجاد کنترلر

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

<?php
 
namespace App\Http\Controllers;
 
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\View\View;
 
class PostController extends Controller
{
    /**
     * Show the form to create a new blog post.
     */
    public function create(): View
    {
        return view('post.create');
    }
 
    /**
     * Store a new blog post.
     */
    public function store(Request $request): RedirectResponse
    {
        // Validate and store the blog post...
 
        $post = /** ... */
 
        return to_route('post.show', ['post' => $post->id]);
    }
}

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

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

اگر اعتبارسنجی در طول یک درخواست HTTP سنتی ناموفق باشد، یک پاسخ تغییر مسیر به URL قبلی ایجاد خواهد شد. اگر درخواست ورودی یک درخواست XHR باشد، یک پاسخ JSON حاوی پیام‌های خطای اعتبارسنجی برگردانده می‌شود.

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

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

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

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

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

علاوه بر این، می‌توانید از این validateWithBag روش برای تأیید اعتبار یک درخواست و ذخیره هرگونه پیام خطا در یک کیسه خطای نام‌گذاری شده استفاده کنید :

$validatedData = $request->validateWithBag('post', [
    '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',
]);

از طرف دیگر، اگر نام فیلد شما حاوی یک نقطه تحت اللفظی باشد، می‌توانید به صراحت از تفسیر آن به صورت «نقطه» با فرار از نقطه با یک اسلش جلوگیری کنید:

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'v1\.0' => 'required',
]);

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

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

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

بنابراین، در مثال ما، زمانی که اعتبارسنجی ناموفق باشد، کاربر به 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 -->

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

قوانین اعتبار سنجی داخلی لاراول هر کدام یک پیام خطا دارند که در lang/en/validation.php فایل برنامه شما قرار دارد. اگر برنامه شما دایرکتوری ندارد lang ، می توانید به لاراول دستور دهید تا با استفاده از lang:publish دستور Artisan آن را ایجاد کند.

در داخل lang/en/validation.php فایل، یک ورودی ترجمه برای هر قانون اعتبار سنجی پیدا خواهید کرد. شما می توانید این پیام ها را بر اساس نیازهای برنامه خود تغییر دهید یا تغییر دهید.

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

به طور پیش فرض، اسکلت برنامه لاراول شامل lang دایرکتوری نمی شود. اگر می خواهید فایل های زبان لاراول را شخصی سازی کنید، می توانید آنها را از طریق lang:publish دستور Artisan منتشر کنید.

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

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

بخشنامه @error ​

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

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

اگر از کیسه های خطای نامگذاری شده استفاده می کنید ، می توانید نام کیسه خطا را به عنوان آرگومان دوم دستورالعمل ارسال کنید @error :

<input ... class="@error('title', 'post') is-invalid @enderror">

جمعیت مجدد فرم ها

هنگامی که لاراول به دلیل خطای اعتبارسنجی پاسخ تغییر مسیر را ایجاد می کند، فریم ورک به طور خودکار تمام ورودی درخواست را به جلسه فلش می کند . این کار به این منظور انجام می‌شود که بتوانید به راحتی در طول درخواست بعدی به ورودی دسترسی داشته باشید و فرمی را که کاربر سعی کرده است ارسال کند دوباره پر کنید.

برای بازیابی ورودی فلش شده از درخواست قبلی، متد را old در یک نمونه از Illuminate\Http\Request . این old روش داده های ورودی فلش شده قبلی را از جلسه خارج می کند :

$title = $request->old('title');

لاراول همچنین یک کمک کننده جهانی ارائه می دهد old . اگر ورودی قدیمی را در قالب Blade نمایش می دهید ، استفاده از old کمک کننده برای پر کردن مجدد فرم راحت تر است . اگر ورودی قدیمی برای فیلد داده شده وجود نداشته باشد، null برگردانده می شود:

<input type="text" name="title" value="{{ old('title') }}">

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

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

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

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

فرمت پاسخ خطای اعتبارسنجی

هنگامی که برنامه شما یک Illuminate\Validation\ValidationException استثنا ایجاد می کند و درخواست HTTP دریافتی منتظر پاسخ JSON است، لاراول به طور خودکار پیام های خطا را برای شما قالب بندی می کند و یک 422 Unprocessable Entity پاسخ HTTP برمی گرداند.

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

{
    "message": "The team name must be a string. (and 4 more errors)",
    "errors": {
        "team_name": [
            "The team name must be a string.",
            "The team name must be at least 1 characters."
        ],
        "authorization.role": [
            "The selected authorization.role is invalid."
        ],
        "users.0.email": [
            "The users.0.email field is required."
        ],
        "users.2.email": [
            "The users.2.email must be a valid email address."
        ]
    }
}

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

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

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

php artisan make:request StorePostRequest

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

همانطور که ممکن است حدس زده باشید، authorize متد مسئول تعیین اینکه آیا کاربر تأیید شده فعلی می‌تواند عملکردی را که توسط درخواست نشان داده شده است انجام دهد یا خیر، در حالی که این rules روش قوانین اعتبارسنجی را که باید برای داده‌های درخواست اعمال شود را برمی‌گرداند:

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

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

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

/**
 * Store a new blog post.
 */
public function store(StorePostRequest $request): RedirectResponse
{
    // The incoming request is valid...
 
    // Retrieve the validated input data...
    $validated = $request->validated();
 
    // Retrieve a portion of the validated input data...
    $validated = $request->safe()->only(['name', 'email']);
    $validated = $request->safe()->except(['name', 'email']);
 
    // Store the blog post...
 
    return redirect('/posts');
}

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

آیا می‌خواهید اعتبار درخواست فرم بلادرنگ را به لاراول لاراول خود که دارای اینرسی است اضافه کنید؟ Laravel Precognition را بررسی کنید .

انجام اعتبار سنجی اضافی

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

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

use Illuminate\Validation\Validator;
 
/**
 * Get the "after" validation callables for the request.
 */
public function after(): array
{
    return [
        function (Validator $validator) {
            if ($this->somethingElseIsInvalid()) {
                $validator->errors()->add(
                    'field',
                    'Something is wrong with this field!'
                );
            }
        }
    ];
}

همانطور که اشاره شد، آرایه ای که توسط after متد برگردانده می شود ممکن است شامل کلاس های فراخوانی نیز باشد. متد __invoke این کلاس ها یک Illuminate\Validation\Validator نمونه دریافت می کند:

use App\Validation\ValidateShippingTime;
use App\Validation\ValidateUserStatus;
use Illuminate\Validation\Validator;
 
/**
 * Get the "after" validation callables for the request.
 */
public function after(): array
{
    return [
        new ValidateUserStatus,
        new ValidateShippingTime,
        function (Validator $validator) {
            //
        }
    ];
}

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

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

/**
 * Indicates if the validator should stop on the first rule failure.
 *
 * @var bool
 */
protected $stopOnFirstFailure = true;

سفارشی کردن تغییر مسیر مکان

همانطور که قبلاً بحث شد، یک پاسخ تغییر مسیر برای ارسال کاربر به مکان قبلی خود در صورت عدم موفقیت در تأیید درخواست فرم ایجاد می شود. با این حال، شما آزاد هستید که این رفتار را سفارشی کنید. برای انجام این کار، یک $redirect ویژگی را در درخواست فرم خود تعریف کنید:

/**
 * The URI that users should be redirected to if validation fails.
 *
 * @var string
 */
protected $redirect = '/dashboard';

یا اگر می‌خواهید کاربران را به مسیری با نام هدایت کنید، می‌توانید $redirectRoute به جای آن یک ویژگی را تعریف کنید:

/**
 * The route that users should be redirected to if validation fails.
 *
 * @var string
 */
protected $redirectRoute = 'dashboard';

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

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

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

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

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

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

return $this->user()->can('update', $this->comment);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/**
 * Handle a passed validation attempt.
 */
protected function passedValidation(): void
{
    $this->replace(['name' => 'Taylor']);
}

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

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

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

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

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

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

این stopOnFirstFailure روش به تأیید کننده اطلاع می‌دهد که باید اعتبارسنجی همه ویژگی‌ها را پس از وقوع یک شکست اعتبارسنجی متوقف کند:

if ($validator->stopOnFirstFailure()->fails()) {
    // ...
}

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

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

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

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

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

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

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

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

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

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

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

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

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

در این مثال، :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 email address!',
];

تعیین مقادیر مشخصه سفارشی

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

$validator = Validator::make($input, $rules, $messages, [
    'email' => 'email address',
]);

انجام اعتبار سنجی اضافی

گاهی اوقات لازم است پس از تکمیل اعتبار اولیه، اعتبار سنجی بیشتری انجام دهید. شما می توانید این کار را با استفاده از روش اعتبار سنجی انجام دهید after . این after روش بسته شدن یا آرایه‌ای از فراخوان‌ها را می‌پذیرد که پس از تکمیل اعتبارسنجی فراخوانی می‌شوند. تماس‌های داده شده Illuminate\Validation\Validator نمونه‌ای دریافت می‌کنند که به شما امکان می‌دهد در صورت لزوم پیام‌های خطای دیگری را ارسال کنید:

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

همانطور که اشاره شد، این after متد همچنین آرایه ای از فراخوانی ها را می پذیرد، که به ویژه اگر منطق "after validation" شما در کلاس های فراخوانی کپسوله شده باشد، راحت است، که نمونه ای را از طریق متد Illuminate\Validation\Validator خود دریافت می کنند: __invoke

use App\Validation\ValidateShippingTime;
use App\Validation\ValidateUserStatus;
 
$validator->after([
    new ValidateUserStatus,
    new ValidateShippingTime,
    function ($validator) {
        // ...
    },
]);

کار با ورودی معتبر

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

$validated = $request->validated();
 
$validated = $validator->validated();

از طرف دیگر، می توانید safe روش را در یک درخواست فرم یا نمونه اعتبارسنجی فراخوانی کنید. این متد یک نمونه از Illuminate\Support\ValidatedInput . این شی only , except و all متدهایی را برای بازیابی زیرمجموعه ای از داده های معتبر یا کل آرایه داده های تایید شده در معرض دید قرار می دهد:

$validated = $request->safe()->only(['name', 'email']);
 
$validated = $request->safe()->except(['name', 'email']);
 
$validated = $request->safe()->all();

علاوه بر این، Illuminate\Support\ValidatedInput نمونه ممکن است تکرار شود و مانند یک آرایه قابل دسترسی باشد:

// Validated data may be iterated...
foreach ($request->safe() as $key => $value) {
    // ...
}
 
// Validated data may be accessed as an array...
$validated = $request->safe();
 
$email = $validated['email'];

اگر می‌خواهید فیلدهای دیگری را به داده‌های تایید شده اضافه کنید، می‌توانید merge روش زیر را فراخوانی کنید:

$validated = $request->safe()->merge(['name' => 'Taylor Otwell']);

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

$collection = $request->safe()->collect();

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

پس از فراخوانی 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')) {
    // ...
}

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

قوانین اعتبار سنجی داخلی لاراول هر کدام یک پیام خطا دارند که در lang/en/validation.php فایل برنامه شما قرار دارد. اگر برنامه شما دایرکتوری ندارد lang ، می توانید به لاراول دستور دهید تا با استفاده از lang:publish دستور Artisan آن را ایجاد کند.

در داخل lang/en/validation.php فایل، یک ورودی ترجمه برای هر قانون اعتبار سنجی پیدا خواهید کرد. شما می توانید این پیام ها را بر اساس نیازهای برنامه خود تغییر دهید یا تغییر دهید.

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

به طور پیش فرض، اسکلت برنامه لاراول شامل lang دایرکتوری نمی شود. اگر می خواهید فایل های زبان لاراول را شخصی سازی کنید، می توانید آنها را از طریق lang:publish دستور Artisan منتشر کنید.

پیام های سفارشی برای ویژگی های خاص

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

'custom' => [
    'email' => [
        'required' => 'We need to know your email address!',
        'max' => 'Your email address is too long!'
    ],
],

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

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

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

به طور پیش فرض، اسکلت برنامه لاراول شامل lang دایرکتوری نمی شود. اگر می خواهید فایل های زبان لاراول را شخصی سازی کنید، می توانید آنها را از طریق lang:publish دستور Artisan منتشر کنید.

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

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

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

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

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

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

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

به طور پیش فرض، اسکلت برنامه لاراول شامل lang دایرکتوری نمی شود. اگر می خواهید فایل های زبان لاراول را شخصی سازی کنید، می توانید آنها را از طریق lang:publish دستور Artisan منتشر کنید.

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

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

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

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

پذیرفته شده

فیلد مورد تایید باید "yes" , "on" , 1 , , یا . این برای تأیید پذیرش «شرایط خدمات» یا فیلدهای مشابه مفید است. "1" true "true"

accepted_if:دیگر فیلد، ارزش،...

فیلد تحت اعتبارسنجی باید "yes" , "on" , , , یا اگر فیلد دیگری 1 که در حال اعتبارسنجی است برابر با مقدار مشخصی باشد. این برای تأیید پذیرش «شرایط خدمات» یا فیلدهای مشابه مفید است. "1" true "true"

فعال_url

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

بعد از: تاریخ

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

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

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

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

after_or_equal: تاریخ

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

آلفا

فیلد مورد تأیید باید کاملاً از نویسه‌های الفبای یونیکد موجود در \p{L} و \p{M} .

برای محدود کردن این قانون اعتبارسنجی به کاراکترهای موجود در محدوده ASCII ( a-z و A-Z )، می‌توانید ascii گزینه‌ای را برای قانون اعتبارسنجی ارائه دهید:

'username' => 'alpha:ascii',

alpha_dash

فیلد مورد تأیید باید کاملاً از نویسه‌های الفبا-عددی یونیکد موجود در \p{L} , \p{M} , \p{N} و همچنین خط تیره ASCII ( - ) و زیرخط ASCII ( _ ) باشد.

برای محدود کردن این قانون اعتبارسنجی به کاراکترهای موجود در محدوده ASCII ( a-z و A-Z )، می‌توانید ascii گزینه‌ای را برای قانون اعتبارسنجی ارائه دهید:

'username' => 'alpha_dash:ascii',

alpha_num

فیلد تحت اعتبارسنجی باید کاملاً از نویسه‌های عددی-الفای یونیکد موجود در \p{L} ، \p{M} و و باشد \p{N} .

برای محدود کردن این قانون اعتبارسنجی به کاراکترهای موجود در محدوده ASCII ( a-z و A-Z )، می‌توانید ascii گزینه‌ای را برای قانون اعتبارسنجی ارائه دهید:

'username' => 'alpha_num:ascii',

آرایه

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

هنگامی که مقادیر اضافی به قانون ارائه می شود array ، هر کلید در آرایه ورودی باید در لیست مقادیر ارائه شده به قانون وجود داشته باشد. در مثال زیر، admin کلید در آرایه ورودی نامعتبر است زیرا در لیست مقادیر ارائه شده به قانون وجود ندارد array :

use Illuminate\Support\Facades\Validator;
 
$input = [
    'user' => [
        'name' => 'Taylor Otwell',
        'username' => 'taylorotwell',
        'admin' => true,
    ],
];
 
Validator::make($input, [
    'user' => 'array:name,username',
]);

به طور کلی، همیشه باید کلیدهای آرایه ای را که مجاز به حضور در آرایه شما هستند، مشخص کنید.

آسکی

فیلد مورد تأیید باید کاملاً 7 بیتی کاراکترهای ASCII باشد.

وثیقه

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

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

if ($validator->stopOnFirstFailure()->fails()) {
    // ...
}

قبل از: تاریخ

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

before_or_equal: تاریخ

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

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

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

بولی

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

تایید شده

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

current_password

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

'password' => 'current_password:api'

تاریخ

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

date_equals: تاریخ

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

date_format: قالب ،...

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

اعشاری: حداقل ، حداکثر

فیلد مورد تأیید باید عددی باشد و باید دارای تعداد مشخص شده اعشار باشد:

// Must have exactly two decimal places (9.99)...
'price' => 'decimal:2'
 
// Must have between 2 and 4 decimal places...
'price' => 'decimal:2,4'

نپذیرفتن

فیلد مورد تایید باید "no" , "off" , 0 , , یا . "0" false "false"

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

فیلد تحت اعتبارسنجی باید "no" , "off" , , , یا اگر فیلد دیگری 0 که در حال اعتبارسنجی است برابر با مقدار مشخصی باشد. "0" false "false"

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

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

ارقام: ارزش

عدد صحیح تحت اعتبار باید دارای طول دقیق مقدار باشد .

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

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

ابعاد

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

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

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

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

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

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

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

متمایز

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

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

Distinct به طور پیش فرض از مقایسه متغیرهای سست استفاده می کند. برای استفاده از مقایسه های دقیق، می توانید strict پارامتر را به تعریف قانون اعتبارسنجی خود اضافه کنید:

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

می‌توانید ignore_case به آرگومان‌های قانون اعتبارسنجی اضافه کنید تا این قانون تفاوت‌های حروف بزرگ را نادیده بگیرد:

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

با: فو ، بار ،... شروع نمی‌شود

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

doest_end_with: foo , bar ,...

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

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

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

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

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

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

اعتبار سنجی dns و به پسوند spoof PHP نیاز دارند intl .

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

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

enum

این Enum قانون یک قانون مبتنی بر کلاس است که تأیید می کند آیا فیلد تحت اعتبارسنجی دارای یک مقدار enum معتبر است یا خیر. قانون Enum نام enum را به عنوان تنها آرگومان سازنده خود می پذیرد. هنگام اعتبارسنجی مقادیر اولیه، یک Enum پشتوانه شده باید به قانون ارائه شود Enum :

use App\Enums\ServerStatus;
use Illuminate\Validation\Rule;
 
$request->validate([
    'status' => [Rule::enum(ServerStatus::class)],
]);

قوانین و روش‌ها ممکن است برای محدود کردن موارد enum معتبر استفاده شوند Enum : only except

Rule::enum(ServerStatus::class)
    ->only([ServerStatus::Pending, ServerStatus::Active]);
 
Rule::enum(ServerStatus::class)
    ->except([ServerStatus::Pending, ServerStatus::Active]);

این when روش ممکن است برای اصلاح Enum قاعده مشروط استفاده شود:

use Illuminate\Support\Facades\Auth;
use Illuminate\Validation\Rule;
 
Rule::enum(ServerStatus::class)
    ->when(
        Auth::user()->isAdmin(),
        fn ($rule) => $rule->only(...),
        fn ($rule) => $rule->only(...),
    );

حذف کردن

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

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

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

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

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
 
Validator::make($request->all(), [
    'role_id' => Rule::excludeIf($request->user()->is_admin),
]);
 
Validator::make($request->all(), [
    'role_id' => Rule::excludeIf(fn () => $request->user()->is_admin),
]);

exclude_less: otherfield , value

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

exclude_with: میدان دیگر

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

exclude_without: otherfield

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

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

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

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

'state' => 'exists:states'

اگر column گزینه مشخص نشده باشد، از نام فیلد استفاده می شود. بنابراین، در این مورد، قانون تأیید می‌کند که states جدول پایگاه داده حاوی رکوردی با state مقدار ستونی است که با مقدار ویژگی درخواست مطابقت دارد state .

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

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

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

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

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

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

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

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

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

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

'state' => Rule::exists('states', 'abbreviation'),

پسوند: foo ، bar ،...

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

'photo' => ['required', 'extensions:jpg,png'],

شما هرگز نباید به اعتبار یک فایل تنها با پسوند اختصاص داده شده توسط کاربر تکیه کنید. این قانون معمولاً باید همیشه در ترکیب با قوانین mimes یا قوانین استفاده شود mimetypes .

فایل

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

پر شده است

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

gt: میدان

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

gte: میدان

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

hex_color

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

تصویر

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

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

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

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

هنگامی که in قانون با array قانون ترکیب می شود، هر مقدار در آرایه ورودی باید در لیست مقادیر ارائه شده به in قانون وجود داشته باشد. در مثال زیر، LAS کد فرودگاه در آرایه ورودی نامعتبر است زیرا در لیست فرودگاه‌های ارائه‌شده به قانون موجود نیست in :

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
 
$input = [
    'airports' => ['NYC', 'LAS'],
];
 
Validator::make($input, [
    'airports' => [
        'required',
        'array',
    ],
    'airports.*' => Rule::in(['NYC', 'LIT']),
]);

in_array: otherfield .*

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

عدد صحیح

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

این قانون اعتبار سنجی تأیید نمی کند که ورودی از نوع متغیر "integer" باشد، فقط ورودی از نوعی است که توسط FILTER_VALIDATE_INT قانون PHP پذیرفته شده است. اگر نیاز دارید ورودی را به عنوان یک عدد تأیید کنید، لطفاً از این قانون در ترکیب با قانون numeric اعتبارسنجی استفاده کنید .

آی پی

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

ipv4

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

ipv6

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

json

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

lt: میدان

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

lte: میدان

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

حروف کوچک

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

فهرست

فیلد تحت اعتبارسنجی باید آرایه ای باشد که یک لیست است. یک آرایه در صورتی یک لیست در نظر گرفته می شود که کلیدهای آن از اعداد متوالی از 0 تا 0 تشکیل شده باشد count($array) - 1 .

مک_آدرس

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

حداکثر: ارزش

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

max_digits: مقدار

عدد صحیح تحت اعتبارسنجی باید دارای حداکثر طول مقدار باشد .

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

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

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

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

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

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

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

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

https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types

انواع MIME و برنامه های افزودنی

این قانون اعتبارسنجی توافق بین نوع MIME و پسوندی را که کاربر به فایل اختصاص داده است تأیید نمی کند. برای مثال، mimes:png قانون اعتبارسنجی فایلی را که حاوی محتوای PNG معتبر است، یک تصویر PNG معتبر در نظر می‌گیرد، حتی اگر نام فایل باشد photo.txt . اگر می‌خواهید پسوند اختصاص داده شده توسط کاربر را تأیید کنید، می‌توانید از extensions قانون استفاده کنید.

دقیقه: ارزش

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

min_digits: مقدار

عدد صحیح تحت اعتبار باید دارای حداقل طول مقدار باشد .

multiple_of: مقدار

فیلد مورد تایید باید مضربی از مقدار باشد .

گم شده

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

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

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

missing_less: otherfield , value

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

missing_with: foo ، bar ،...

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

missing_with_all: foo ، bar ،...

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

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 .

عددی

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

حاضر

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

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

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

present_less: otherfield , value

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

present_with: Foo , Bar ,...

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

present_with_all: Foo , Bar ,...

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

ممنوع است

فیلد مورد تأیید باید مفقود یا خالی باشد. یک فیلد در صورتی خالی است که یکی از معیارهای زیر را داشته باشد:

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

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

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

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
 
Validator::make($request->all(), [
    'role_id' => Rule::prohibitedIf($request->user()->is_admin),
]);
 
Validator::make($request->all(), [
    'role_id' => Rule::prohibitedIf(fn () => $request->user()->is_admin),
]);

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

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

ممنوع می کند: میدان دیگر ،...

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

regex: الگو

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

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

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

ضروری

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

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

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

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

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
 
Validator::make($request->all(), [
    'role_id' => Rule::requiredIf($request->user()->is_admin),
]);
 
Validator::make($request->all(), [
    'role_id' => Rule::requiredIf(fn () => $request->user()->is_admin),
]);

require_if_accepted: یک فیلد دیگر ،...

اگر فیلد دیگری برابر با "yes" , "on" , 1 , "1" , true یا , فیلد تحت اعتبارسنجی باید وجود داشته باشد و خالی نباشد "true" .

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

فیلد تحت اعتبارسنجی باید موجود باشد و خالی نباشد مگر اینکه فیلد دیگری با هر مقداری برابر باشد . این همچنین به این معنی است که فیلد دیگری باید در داده های درخواست وجود داشته باشد مگر اینکه مقدار باشد null . اگر مقدار null ( ) باشد required_unless:name,null ، فیلد تحت اعتبارسنجی مورد نیاز خواهد بود، مگر اینکه فیلد مقایسه باشد null یا فیلد مقایسه در داده درخواست وجود نداشته باشد.

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

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

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

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

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

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

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