Adding HTTP request parameter rules - PingAccess

Adding HTTP request parameter rules - PingAccess - 7.2

PingAccess

bundle

pingaccess-72

ft:publication_title

PingAccess

Product_Version_ce

PingAccess 7.2

category

Product

pa-72

pingaccess

ContentType_ce

Add an HTTP request parameter rule to examine a request and determine whether to grant access to a requested resource based on a match found in specified form parameters of the HTTP request.

Add an HTTP request parameter rule determines if the parameters are passed as part of the URLURLURL (Uniform Resource Locator) Identifies a resource according to its Internet location. query string parameters or as part of a request body submitted using an HTTP PUT or POST method. If the request is a POST request, the content-type must be set to application/x-www-form-urlencoded to process the field names in the request.

If this rule is applied to an agent configuration, only URL query string parameters are compared, because the agent does not receive the request body for processing.

If more than one Field and Value pair is listed, then all conditions must match for the rule to succeed.

Click Access and then go to Rules > Rules.
Click + Add Rule.
In the Name field, enter a unique name, up to 64 characters long.

Special characters and spaces are allowed.
From the Type list, select HTTP Request Parameter.
In the Field column, in the Parameter field, enter a parameter name you want to match to grant or not grant the client access.
In the Value field, enter a value for the parameter you want to match in order to grant or deny the client access.

The wildcard (*) character is supported.

Note:
Values entered here will be URL-encoded prior to the comparison. For example, if the value specified in the Value field is v1 v2, when the engine performs the comparison, this value will convert to v1%20v2 before the search is performed.
If additional parameters pairs are needed, click Add Row to add an additional row, then repeat steps 5-6.
If the values should be an exact match to the value case, select the Case Sensitive check box.
If access is not allowed when a match is found, select the Negate check box.

Info:
Ensure that the field name you enter is spelled correctly and exists. If you enter a field name that does not exist and you select Negate, the rule will always succeed. The Negate control applies to the entire set of conditions specified, and passes the rule if any condition is not met.
Optional: To configure rejection handling, click Show Advanced Settings, then select a rejection handling method.
- If you select Default, use the Rejection Handler list to select an existing rejection handler that defines whether to display an error template or redirect to a URL.
- If you select Basic, you can customize an error message to display as part of the default error page rendered in the end user's browser if rule evaluation fails. This page is among the templates you can modify with your own branding or other information. If you select Basic, provide the following:
  1. In the Error Response Code field, enter the HTTP status response code to send if rule evaluation fails.
    The default is 403.
  2. In the Error Response Status Message field, enter the HTTP status response message to send if rule evaluation fails.
    The default is Forbidden.
  3. In the Error Response Template File field, enter the HTML template page for customizing the error message that displays if rule evaluation fails. This template file is located in the <PA_HOME>/conf/template/ directory.
  4. From the Error Response Content Type list, select the type of content for the error response.
    This lets the client properly display the response.
Click Save.