Laravel
Uprawomocnienie

Parametry

Podstawowy przykład

Możesz zweryfikować dane żądania, używając metody validate (dostępnej w podstawowym kontrolerze, dostarczonej przez cechę ValidatesRequests ).

Jeśli reguły przejdą pomyślnie, Twój kod będzie działał normalnie; jeśli jednak sprawdzanie poprawności się nie powiedzie, odpowiedź błędu zawierająca błędy sprawdzania poprawności zostanie automatycznie odesłana:

• w przypadku typowych formularzy HTML użytkownik zostanie przekierowany na poprzednią stronę, przy czym formularz zachowa przesłane wartości
• dla żądań oczekujących odpowiedzi JSON zostanie wygenerowana odpowiedź HTTP z kodem 422

Na przykład w UserController możesz zapisywać nowego użytkownika w metodzie store , który przed zapisaniem wymagałby sprawdzenia.

/**
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request) {
    $this->validate($request, [
        'name' => 'required',
        'email' => 'email|unique:users|max:255'
    ],
    // second array of validation messages can be passed here
    [
        'name.required' => 'Please provide a valid name!',
        'email.required' => 'Please provide a valid email!',
    ]);

    // The validation passed
}

W powyższym przykładzie potwierdzamy, że pole name istnieje z niepustą wartością. Po drugie, należy sprawdzić, czy email pole ma poprawny format e-mail, jest unikalny w tabeli bazy danych „użytkowników”, i ma maksymalną długość 255 znaków.

The | Znak (potok) łączy różne reguły sprawdzania poprawności dla jednego pola.

Czasami możesz chcieć zatrzymać reguły sprawdzania poprawności dla atrybutu po pierwszym niepowodzeniu sprawdzania poprawności. W tym celu przypisz regułę bail do atrybutu:

$this->validate($request, [
    'name' => 'bail|required',
    'email' => 'email|unique:users|max:255'
]);

Pełna lista dostępnych reguł sprawdzania poprawności znajduje się w sekcji parametrów poniżej .

Sprawdzanie poprawności macierzy

Sprawdzanie poprawności pól wejściowych formularza tablicowego jest bardzo proste.

Załóżmy, że musisz zweryfikować każde imię, adres e-mail i nazwisko ojca w danej tablicy. Możesz wykonać następujące czynności:

$validator = \Validator::make($request->all(), [
    'name.*'       => 'required', 
    'email.*'      => 'email|unique:users',
    'fatherName.*' => 'required'
]);

if ($validator->fails()) {
    return back()->withInput()->withErrors($validator->errors());
}

Laravel wyświetla domyślne komunikaty do weryfikacji. Jeśli jednak chcesz niestandardowe komunikaty dla pól opartych na tablicach, możesz dodać następujący kod:

[
    'name.*' => [
        'required' => 'Name field is required',
    ],
    'email.*' => [
        'unique'   => 'Unique Email is required',
    ],
    'fatherName.*' => [
        'required' => 'Father Name required',
    ]
]

Twój końcowy kod będzie wyglądał następująco:

$validator = \Validator::make($request->all(), [
    'name.*'       => 'required', 
    'email.*'      => 'email|unique:users',
    'fatherName.*' => 'required',
], [
    'name.*'       => 'Name Required',
    'email.*'      => 'Unique Email is required',
    'fatherName.*' => 'Father Name required',
]);

if ($validator->fails()) {
    return back()->withInput()->withErrors($validator->errors());
}

Inne metody walidacji

1) Sprawdzanie poprawności formularza

Możesz utworzyć „formularz wniosku”, który może zawierać logikę autoryzacji, reguły sprawdzania poprawności i komunikaty o błędach dla konkretnego żądania w aplikacji.

Komenda make:request Artisan CLI generuje klasę i umieszcza ją w katalogu app/Http/Requests :

php artisan make:request StoreBlogPostRequest

Metodę authorize można zastąpić logiką autoryzacji dla tego żądania:

public function authorize()
{        
    return $this->user()->can('post');
}

Metodę rules można zastąpić szczegółowymi regułami dla tego żądania:

public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

Metodę messages można zastąpić konkretnymi komunikatami dla tego żądania:

public function messages()
{
    return [
        'title.required' => 'A title is required',
        'title.unique' => 'There is another post with the same title',
        'title.max' => 'The title may not exceed :max characters',
        'body.required' => 'A message is required',
    ];
}

Aby zweryfikować żądanie, po prostu wpisz wskazówkę dotyczącą konkretnej klasy żądania w odpowiedniej metodzie kontrolera. Jeśli sprawdzanie poprawności się nie powiedzie, odpowiedź błędu zostanie odesłana.

public function store(StoreBlogPostRequest $request)
{
    // validation passed
}

2) Ręczne tworzenie walidatorów

Aby uzyskać większą elastyczność, możesz ręcznie utworzyć walidator i bezpośrednio obsłużyć nieudaną weryfikację:

<?php    
namespace App\Http\Controllers;

use Validator;
use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class PostController extends Controller
{
    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...
    }
}

2) Płynne tworzenie reguł

Czasami może być konieczne tworzenie unikalnych reguł w locie, praca z metodą boot() w ramach dostawcy usług może być nadrzędna, ponieważ w Laravel 5.4 możesz płynnie tworzyć nowe reguły za pomocą klasy Rule .

Jako przykład będziemy pracować z UserRequest gdy chcesz wstawić lub zaktualizować użytkownika. Na razie chcemy, aby nazwa była wymagana, a adres e-mail musi być unikalny. Problem z używaniem unique reguły polega na tym, że jeśli edytujesz użytkownika, może on przechowywać ten sam adres e-mail, więc musisz wykluczyć bieżącego użytkownika z reguły. Poniższy przykład pokazuje, jak łatwo to zrobić, korzystając z nowej klasy Rule .

<?php
namespace App\Http\Requests;
use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\Request;
use Illuminate\Validation\Rule;

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

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules(Request $request)
    {
        $id = $request->route()->getParameter('user');

        return [
            'name'           =>  'required',
            
            // Notice the value is an array and not a string like usual
            'email'         =>  [
                'required',
                Rule::unique('users')->ignore($id)
            ]
        ];
    }
}

Klasa pojedynczego formularza dla POST, PUT, PATCH

Zgodnie z przykładem „Walidacja żądania formularza” ta sama klasa żądania może być używana dla POST , PUT , PATCH więc nie trzeba tworzyć innej klasy przy użyciu tych samych / podobnych walidacji. Jest to przydatne, jeśli masz unikalne atrybuty w tabeli.

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules() {
    switch($this->method()) {
        case 'GET':
        case 'DELETE':
            return [];
        case 'POST':
            return [
                'name'     => 'required|max:75|unique',
                'category' => 'required',
                'price'    => 'required|between:0,1000',
            ];
        case 'PUT':
        case 'PATCH':
            return [
                'name'     => 'required|max:75|unique:product,name,' . $this->product,
                'category' => 'required',
                'price'    => 'required|between:0,1000',
            ];
        default:break;
    }
}

Począwszy od góry, nasza instrukcja switch będzie analizować typ metody żądania ( GET , DELETE , POST , PUT , PATCH ).

W zależności od metody zwróci tablicę zdefiniowanych reguł. Jeśli masz unikalne pole, takie jak pole name w przykładzie, musisz podać konkretny identyfikator, aby sprawdzanie poprawności miało zostać zignorowane.

'field_name' => 'unique:table_name,column_name,' . $idToIgnore`

Jeśli masz klucz podstawowy oznaczony czymś innym niż id , jako kolumnę czwartego parametru określisz kolumnę klucza podstawowego.

'field_name' => 'unique:table_name,column_name,' . $idToIgnore . ',primary_key_column'

W tym przykładzie używamy PUT i przekazujemy do trasy ( admin/products/{product} ) wartość identyfikatora produktu. Więc $this->product będzie równy id do zignorowania.

Teraz Twoje reguły sprawdzania poprawności PUT|PATCH i POST nie muszą być takie same. Zdefiniuj swoją logikę, która odpowiada Twoim wymaganiom. Ta technika umożliwia ponowne użycie niestandardowych wiadomości, które zostały zdefiniowane w niestandardowej klasie żądania formularza.

Komunikaty o błędach

Dostosowywanie komunikatów o błędach

Pliki /resources/lang/[lang]/validation.php zawierają komunikaty o błędach do wykorzystania przez moduł sprawdzający poprawność. Możesz je edytować w razie potrzeby.

Większość z nich ma symbole zastępcze, które zostaną automatycznie zastąpione podczas generowania komunikatu o błędzie.

Na przykład w 'required' => 'The :attribute field is required.' , symbol zastępczy :attribute zostanie zastąpiony nazwą pola (alternatywnie można również dostosować wartość wyświetlaną każdego pola w tablicy attributes w tym samym pliku).

Przykład

konfiguracja wiadomości:

'required' => 'Please inform your :attribute.',
//...
'attributes => [
    'email' => 'E-Mail address'
]

zasady:

`email' => `required`

wynikowy komunikat o błędzie:

„Proszę podać swój adres e-mail”.

Dostosowywanie komunikatów o błędach w klasie żądania

Klasa Request ma dostęp do metody messages() , która powinna zwrócić tablicę, można jej użyć do przesłonięcia wiadomości bez konieczności przechodzenia do plików lang. Na przykład, jeśli mamy niestandardową weryfikację file_exists możesz wysyłać wiadomości takie jak poniżej.

class SampleRequest extends Request {

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'image' =>  'required|file_exists'
        ];
    }

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

    public function messages()
    {
        return [
            'image.file_exists' =>  'That file no longer exists or is invalid'
        ];
    }

}

Wyświetlanie komunikatów o błędach

Błędy sprawdzania poprawności są rzutowane na sesję i są również dostępne w zmiennej $errors , która jest automatycznie udostępniana wszystkim widokom.

Przykład wyświetlania błędów w widoku ostrza:

@if (count($errors) > 0)
    <div class="alert alert-danger">
        <ul>
            @foreach ($errors->all() as $error)
                <li>{{ $error }}</li>
            @endforeach
        </ul>
    </div>
@endif

Niestandardowe reguły sprawdzania poprawności

Jeśli chcesz utworzyć niestandardową regułę sprawdzania poprawności, możesz to zrobić na przykład w metodzie boot usługodawcy za pośrednictwem fasady Validatora.

<?php
namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Validator;

class AppServiceProvider extends ServiceProvider
{
    public function boot()
    {
        Validator::extend('starts_with', function($attribute, $value, $parameters, $validator) {
            return \Illuminate\Support\Str::startsWith($value, $parameters[0]);
        });

        Validator::replacer('starts_with', function($message, $attribute, $rule, $parameters) {
            return str_replace(':needle', $parameters[0], $message);
        });
    }
}

Metoda extend pobiera ciąg znaków, który będzie nazwą reguły i funkcją, która z kolei przekaże nazwę atrybutu, sprawdzanej wartości, tablicę parametrów reguły i instancję sprawdzania poprawności i powinna zwrócić, czy walidacja mija. W tym przykładzie sprawdzamy, czy ciąg wartości zaczyna się od danego podłańcucha.

Komunikat o błędzie dla tej reguły niestandardowej można ustawić jak zwykle w pliku /resources/lang/[lang]/validation.php i może on zawierać symbole zastępcze, na przykład dla wartości parametrów:

'starts_with' => 'The :attribute must start with :needle.'

Metoda replacer pobiera ciąg znaków, który jest nazwą reguły i funkcją, która z kolei przekaże oryginalną wiadomość (przed zastąpieniem), nazwę atrybutu, nazwę reguły i tablicę parametrów reguły, i powinien zwrócić wiadomość po wymianie symboli zastępczych w razie potrzeby.

Użyj tej reguły jak każdej innej:

$this->validate($request, [
    'phone_number' => 'required|starts_with:+'
]);