There are a lot of times when you need to validate incoming input either from a form or from an incoming json request. It is wise to have some form of backend validation as it will allow you to build more secure applications. Masonite provides an extremely flexible and fluent way to validate this data.
Validations are based on rules where you can pass in a key or a list of keys to the rule. The validation will then use all the rules and apply them to the dictionary to validate.
Incoming form or JSON data can be validated very simply. All you need to do is import the Validator class, resolve it, and use the necessary rule methods.
This whole snippet will look like this in your controller method:
This validating will read like "user and email are required and the terms must be accepted" (more on available rules and what they mean in a bit)
Note you can either pass in a single value or a list of values
Creating a Rule
Sometimes you may cross a time where you need to create a new rule that isn't available in Masonite or there is such a niche use case that you need to build a rule for.
In this case you can create a new rule.
Rule Command
You can easily create a new rule boiler plate by running:
$craftruleequals_masonite
There is no particular reason that rules are lowercase class names. The main reason it is improves readability when you end up using it as a method if you choose to register the rule with the validation class like you will see below.
This will create a boiler plate rule inside app/rules/equals_masonite.py that looks like:
classequals_masonite(BaseValidation):"""A rule_name validation class """defpasses(self,attribute,key,dictionary):"""The passing criteria for this rule. ... """return attributedefmessage(self,key):"""A message to show when this rule fails ... """return'{} is required'.format(key)defnegated_message(self,key):"""A message to show when this rule is negated using a negation rule like 'isnt()' ... """return'{} is not required'.format(key)
Constructing our Rule
Our rule class needs 3 methods that you see when you run the rule command, a passes, message and negated_message methods.
Passes Method
The passes method needs to return some kind of boolean value for the use case in which this rule passes.
For example if you need to make a rule that a value always equals Masonite then you can make the method look like this:
defpasses(self,attribute,key,dictionary):"""The passing criteria for this rule. ... """return attribute =='Masonite'
When validating a dictionary like this:
{'name':'Masonite'}
then
the attribute will be the value (Masonite)
the key will be the dictionary key (name)
the dictionary will be the full dictionary in case you need to do any additional checks.
Message method
The message method needs to return a string used as the error message. If you are making the rule above then our rule may so far look something like:
defpasses(self,attribute,key,dictionary):"""The passing criteria for this rule. ... """return attribute =='Masonite'defmessage(self,key):return'{} must be equal to Masonite'.format(key)
Negated Message
The negated message method needs to return a message when this rule is negated. This will basically be a negated statement of the message method:
defpasses(self,attribute,key,dictionary):"""The passing criteria for this rule. ... """return attribute =='Masonite'defmessage(self,key):return'{} must be equal to Masonite'.format(key)defnegated_message(self,key):return'{} must not be equal to Masonite'.format(key)
Registering our Rule
Now the rule is created we can use it in 1 of 2 ways.
Importing our rule
We can either import directly into our controller method:
or we can register our rule and use it with the Validator class as normal.
Register the rule
In any service provider's boot method (preferably a provider where wsgi=False to prevent it from running on every request) we can register our rule with the validator class.
If you don't have a provider yet we can make one specifically for adding custom rules:
$craftproviderRuleProvider
Then inside this rule provider's boot method we can resolve and register our rule. This will look like:
from app.rules.equals_masonite import equals_masonitefrom masonite.validation import ValidatorclassRuleProvider(ServiceProvider):"""Provides Services To The Service Container """ wsgi =False ...defboot(self,validator: Validator):"""Boots services required by the container """ validator.register(equals_masonite)
Now instead of importing the rule we can just use it as normal:
Just put the dictionary as the first argument and then each rule being its own argument.
Using The Decorator
Masonite validation has a convenient decorator you can use on your controller methods. This will prevent the controller method being hit all together if validation isn't correct:
from masonite.validation.decorators import validatefrom masonite.validation import required@validate(required('name'))defshow(self,view: View):return view.render(..)
This will return a JSON response. You can also choose where to redirect back to:
from masonite.validation.decorators import validatefrom masonite.validation import required@validate(required('name'), redirect='/login')defshow(self,view: View):return view.render(..)
As well as redirect back to where you came from (if you use the {{ back() }} template helper)
from masonite.validation.decorators import validatefrom masonite.validation import required@validate(required('name'), back=True)defshow(self,view: View):return view.render(..)
Both of these redirections will redirect with errors and input. So you can use the {{ old() }} template helper to get previous input.
Rule Enclosures
Rule enclosures are self contained classes with rules. You can use these to help reuse your validation logic. For example if you see you are using the same rules often you can use an enclosure to always keep them together and reuse them throughout your code base.
Rule Enclosure Command
You can create a rule enclosure by running:
$ craft rule:enclosure AcceptedTerms
You will then see a file generated like this inside app/rules:
from masonite.validation import RuleEnclosure...classAcceptedTerms(RuleEnclosure):defrules(self):""" ... """return [# Rules go here ]
Creating the Rule Enclosure
You can then fill the list with rules:
from masonite.validation import required, acceptedclassLoginForm(RuleEnclosure):defrules(self):""" ... """return [required(['email', 'terms']),accepted('terms') ]
errors =MessageBag(errors)errors.all()"""{ 'email': ['Your email is required'], 'name': ['Your name is required']}"""errors.first()"""{ 'email': ['Your email is required']}"""
Getting the Number of Errors:
errors =MessageBag(errors)errors.count()#== 2
Converting to JSON
errors =MessageBag(errors)errors.json()"""'{"email": ["Your email is required"],"name": ["Your name is required"]}'"""
Sometimes you will need to check values that aren't on the top level of a dictionary like the examples shown here. In this case we can use dot notation to validate deeper dictionaries:
notice the dot notation here. Each . being a deeper level to the dictionary.
Nested Validations With Lists
Sometimes your validations will have lists and you will need to ensure that each element in the list validates. For example you want to make sure that a user passes in a list of names and ID's.
For this you can use the * asterisk to validate these:
All errors returned will be very generic. Most times you will need to specify some custom error that is more tailored to your user base.
Each rule has a messages keyword arg that can be used to specify your custom errors.
"""{ 'terms': 'off', 'active': 'on',}"""validate.accepted(['terms', 'active'], messages = {'terms': 'You must check the terms box on the bottom','active': 'Make sure you are active'})
Now instead of returning the generic errors, the error message returned will be the one you supplied.
Leaving out a message will result in the generic one still being returned for that value.
Exceptions
By default, Masonite will not throw exceptions when it encounters failed validations. You can force Masonite to raise a ValueError when it hits a failed validation:
You can also specify which exceptions should be thrown with which key being checked by using a dictionary:
try: errors = request.validate( validate.required(['user.email', 'user.id'], raises={'user.id': AttributeError,'user.email': CustomException }), )exceptAttributeErroras e:str(e)#== 'user.id is required'except CustomException as e:str(e)#== 'user.email is required'
All other rules within an explicit exception error will throw the ValueError.
String Validation
In addition to using the methods provided below, you can also use each one as a pipe delimitted string. For example these two validations are identical:
These rules are identical so use whichever feels more comfortable.
Available Rules
Accepted
The accepted rule is most useful when seeing if a checkbox has been checked. When a checkbox is submitted it usually has the value of on so this rule will check to make sure the value is either on, 1, or yes.
"""{ 'terms': 'on'}"""validate.accepted('terms')
Active_domain
This is used to verify that the domain being passed in is a DNS resolvable domain name. You can also do this for email addresses as well. The preferred search is domain.com but Masonite will strip out http://, https:// and www automatically for you.
Used to make sure the date is a date after today. In this example, this will work for any day that is 2019-10-21 or later.
"""{ 'date': '2019-10-20', # Or date in the future}"""validate.after_today('date')
You may also pass in a timezone for this rule:
"""{ 'date': '2019-10-20', # Or date in the future}"""validate.after_today('date', tz='America/New_York')
Before_today
Used to make sure the date is a date before today. In this example, this will work for any day that is 2019-10-19 or earlier.
"""{ 'date': '2019-10-20', # Or date in the past}"""validate.before_today('date')
You may also pass in a timezone for this rule:
"""{ 'date': '2019-10-20', # Or date in the past}"""validate.before_today('date', tz='America/New_York')
Contains
This is used to make sure a value exists inside an iterable (like a list or string). You may want to check if the string contains the value Masonite for example:
"""{ 'description': 'Masonite is an amazing framework'}"""validate.contains('description', 'Masonite')
Confirmed
This rule is used to make sure a key is "confirmed". This is simply a key_confirmation representation of the key.
For example, if you need to confirm a password you would set the password confirmation to password_confirmation.
The strong rule is used to make sure a string has a certain amount of characters required to be considered a "strong" string.
This is really useful for passwords when you want to make sure a password has at least 8 characters, have at least 2 uppercase letters and at least 2 special characters.