Use the Authorized and Early Request Validator API policies to perform generic validation steps on requests and return customized responses. You can use both policies in tandem or just one. For example, if a Task requires a particular HTTP header in a particular format, that can be validated with one of these API policies before incurring the cost of executing a Pipeline.
Policy Execution Order
Although both policies have the same configuration options, the difference between the two API policies is the order of execution:
- The Early Request Validator policy executes before authentication.
- The Authorized Request Validator policy executes after authorization.
Expression Enabled Fields in API Policies All expression enabled fields take expressions from the SnapLogic Expression Language and the API Policy Manager functions.
| Parameter Name | Description | Default Value | Example |
|---|---|---|---|
| Label | Required. The name for the API policy. | Authorized Request Validator Early Request Validator | AuthValUserID EarlyValToken |
| When this policy should be applied | An expression enabled field that determines the condition to be fulfilled for the API policy to execute. | True | request.method == "POST" |
| Validation Checks | A table of checks to perform on the request. | N/A | N/A |
| Condition | An expression that should return true if the request should be aborted. You cannot use request.remoteUser or request.isUserInRole() functions with the Early Request Validator policy since it is applied before authentication happens. Instead, use the Authorized Request Validator policy instead if the Condition checks the values specified by these functions. | False | isNaN(parseInt(request.headers['X-My-Header])) |
| Status | The HTTP Status code to use in the response. | 400 (Bad Request) | 413 (Request Entity Too Large) |
| Response | The response to send to the client. | N/A |
{ 'Content-Type': 'text/html',
}
|
| Status | Indicates whether the API policy is enabled or disabled. | Enabled | Disabled |
These policies allow a great deal of flexibility in determining how a request is handled before it reaches a Pipeline; ss such, you must carefully consider the request flow of your API when configuring this policy.
Example
Use this policy to ensure a request is valid before the Triggered Task is executed by applying these settings in the dialog
- Condition:
!(request.uri.query matches { id: /\d+/ }) - Status:
400 - Response: Try Again
Where the Response expects an ID query parameter that is a number.