WEB4J divides validation tasks into hard validation and soft validation. They are distinguished by :
"Hard" Validation
Hard validation is applied earlier in processing. A failed hard validation represents either a bug, or a malicious request (a "hack"). When a hard validation fails, a curt and unpolished response can be sent. Hard validations are performed by an ApplicationFirewall, ultimately called by the {@link hirondelle.web4j.Controller}, as the first step in processing a request, before any {@link Action} is executed. Items for hard validation might include :
For request parameters, hard validation must include only those checks whose failure would constitute a bug or a malicious request.
"Soft" Validation
Soft validation is applied later in processing. If a soft validation fails, resulting response pages use a polished presentation. They are applied to items that are input directly by the user, for example the content of a text input control. Invalid values are handled as part of the normal operation of the program. Soft validations are "problem domain" validations, and are usually implemented in a Model Object constructor.
To clarify, here are two examples, using the default implementation of {@link ApplicationFirewallImpl}.
Example 1
A select control named Spin submits two fixed values, UP and DOWN. Under normal operation of the program, no other values are expected. In this case, the submitted request parameter should undergo these checks :
Hard validation - must be one of the two values UP or DOWN. This is implemented by simply defining, in the {@link Action} that handles this parameter, a single field :
public static final RequestParameter SPIN = RequestParameter.withRegexCheck("Spin", "(UP|DOWN)");{@link ApplicationFirewallImpl} uses such fields to determine, for each {@link Action}, how to do hard validation for request parameters. It checks permitted parameter names, and permitted parameter values versus a regular expression.
Soft validation - none. In this case, the hard validation checks the parameter value completely, so there is no further validation to be performed.
Example 2
A text input control named Age accepts any text as input. That text should correspond to an integer in the range 0..130. In this case, the validation is shared between hard validation and soft validation :
Hard validation - can only make a basic sanity check. For instance, a check that the parameter value is not an unreasonable size - under 5K, for instance. This is meant only to detect obvious hacks. It has nothing to do with business logic. That is, this size check does not correspond to the maximum number of characters expected (3), since failure of a hard validation produces a response which should not be seen by the typical user during normal operation of the program. In this case, the field declared in the {@link Action}is :
public static final RequestParameter AGE = RequestParameter.withLengthCheck("Age");(The actual maximum length is set in web.xml.)
Soft validation #1 - first, make sure the user input can be translated into an {@link Integer}. This is a very common task, and is implemented by {@link RequestParser}, using its various toXXX methods (and, at a higher lever, by {@link ModelFromRequest}). When user input cannot be parsed into an {@link Integer}, then an error message is displayed to the user. See {@link ConvertParamError}.
Soft validation #2 - make sure the {@link Integer} returned by the previous validation is in the range 0..150. This is an example of a typical business validation. These are usually implemented in the constructor of a Model Object. Again, if a problem is detected, then an error message is displayed to to the user.
{@link hirondelle.web4j.model.Check} and {@link hirondelle.web4j.model.Validator} are provided to help you implement soft validations.
| |