Laravel 5.x: Custom Validation Rules

Sometimes, the default validation rules included in Laravel 5.x isn’t enough for bespoke applications. For example, what if I want a validation rule that checks if a field matches the current user’s password in the database? There isn’t a rule for that, but luckily its fairly easy to add custom rules. This tutorial shows you how.

My requirement was a custom validation rule that checks if the entered password for the user matches the one stored in the database. This is so I can validate the user’s request to update their password. The form would use three fields: current_password, password, password_confirmation, and it’s the current_password that I want to validate.

Including the Required Dependencies

In order to create a custom validation rule, you need to make sure the relevant classes are included in your code. In my example, we need the use statement to include the following classes:

• use Input;
• use Auth;
• use View;
• use Session;
• use Validator;
• use Redirect;
• use Hash;
• use App\User;

Creating the Custom Password Validator

To create the custom validation rule, we use the Validator::extend function to create a new rule called password. The function accepts a name and Closure to create the rule. Lines 10-13 below show how I created the rule for checking the password.

See the gist on github.

I also created the $messages array to include a custom error message should validation fail, and passed this to the Validator::make function (as the third parameter). Here is a line-by-line breakdown:

• Line 4-7 define the validation rules to use on the input fields. We want to check the existing password for the current_password field, and we need the password field confirmed (with the password_confirmation field).
• Lines 10-13 is the custom validation rule itself. Specifically, line 12 preforms the password check by validating the user-submitted $value to what was stored in the database (in the users table, under column password).
• Line 16 is the default error message we’ll use if the validation check fails
• Line 19 is where we put it all together and validate the input. If this fails, it will trigger Lines 22-24 so the user is redirected back to the form with the relevant message displayed.
• Lines 23 redirects the user back to the page they came from, and includes the form data and validation error messages.
• Line 27-29 updates the user’s password if validation passes. This code is only executed if validation passes.
• Line 32 is where the user is redirected on success. In this case, we send them to the previous page with a success message.

Another Example

To give you a better idea of how it all works, here is another example. This time, I’ve created a rule called startswith, which validates that a field starts with the required prefix. In this example, the validation rule also accepts parameters: the prefix. So, if I want to validate that UK Mobile numbers start with ’07’, I would create a custom validator as following:

See the gist on github.

Putting it All Together

One-off validation rules work best in Controllers, for example, the below code shows how the validation rule comes together with other code. If you want your validation rules to be available across multiple files / controllers, you can also register them within a service provider.

See the gist on github.