Nav
You are viewing an older version of this section. Click here to navigate to the latest version.

Anypoint Filter Processor

Generally positioned immediately after an inbound connector in a Mule flow, the Anypoint Filter Processor evaluates two message properties, then rejects the message if the values fall outside of its configured parameters. The properties that are evaluated are:

  • IP address – If the IP address of a message falls outside the filter’s configured IP address range, Mule does not process the message (see image below).

  • Creation timestamps — Where the message’s creation date and time fall outside the filter’s configured acceptable lifespan (i.e. the message is older than expected), Mule does not process the message (see image below).

    filter3

Configuring the Anypoint Filter Processor

Use an Anypoint Filter Processor to protect a network, database, or system from unauthorized access by users outside the network. In other words, use a filter to exclude users from non-authorized IP addresses from accessing your system.

Further, use a security filter to protect your resource against a replay attack. By rejecting messages with a lifespan that exceeds a short timeframe — 30 seconds, for example — Mule protects your application from processing the same message a user maliciously sends multiple times. To be effective, a Mule flow should employ a digital signature, in addition to this type of security filter, to sign the creation time of the message.

This topic introduces the idea of Global Elements; if you are unfamiliar with this functionality, access Understand Global Elements to learn more before proceeding.

The following steps describe how to configure the Anypoint Filter Processor to filter by IP address range.

  1. Add a global Filter Element to your application, apply a unique Name to the element, the only attribute to configure.

  2. Place a Filter message processor in your flow, typically positioned after an inbound connector, such as HTTP, so as to filter out invalid messages early in the flow.

  3. Configure the message processor according to the table below.

    filters

    Field Req’d Value

    Display Name

    x

    A unique name for your message processor.

    Config Reference

    x

    Use the name of the global element you created above.

    Operation

    x

    Filter by ip

    Regex

    Enter a regex expression to apply further rules for filtering messages based on the IP address range.

  4. Add a global filters:config element to your application, set above all the flows in your application.

  5. Configure the global element according to the table below.

Attribute Req’d Value

name

x

A unique name for your element.

doc:name

x

A display name for the element in Studio’s Visual Editor. Not applicable for Standalone.

  1. Place a filter:filter-by-ip element in your flow, typically positioned after an inbound connector, such as HTTP, so as to filter out invalid messages early in the flow.

  2. Configure the message processor according to the table below.

    Field Req’d Value

    config-ref

    x

    Use the name of the global element you created above.

    regex

    Enter a regex expression to apply further rules for filtering messages based on the IP address range.

    doc:name

    x

    A display name for the element in Studio’s Visual Editor. Not applicable for Standalone.

Filter Strategies

The Anypoint Filter processor allows you to filter messages according to the following four filter strategies:

Operation Description Example

Filter by IP

Type an IP address or regular expression to define the address or range from which the Filter will accept connections.

Regex:` 192.168.1.10`, 192.168.1.* (to allow the range from 1.0 to 1.254)

Filter by IP range

Enter a net address and mask to determine the IP range. The IP addresses or ranges you enter will be considered valid, and allowed by the Filter.

Net: 192.168.1.0

Mask: 255.255.255.0

Filter by IP range CIDR

Enter the desired IP range in CIDR notation.

Cidr:` 192.168.1.0/24`

Filter expired

This option allows you to define an expiration time for the message.

  • To define an expiration time based upon the time a message entered the flow, enter a Mule Expression to call a variable that provides this date and time in ISO 8601 format (yyyy-MM-dd’T’hh:mm:ssZ), and an expiration time in milliseconds. (Earlier in the flow, you will need to name and define this variable so that it extracts the date and time information from your message’s metadata.) The expiration time will be calculated based on the timestamp extracted from the message, and the filter will discard messages received after that expiration time.

  • To define an exact date and time after which messages should expire, enter a date and time in ISO 8601 format (yyyy-MM-dd’T’hh:mm:ssZ), and an expiration time in milliseconds. The expiration time is calculated from the precise date and time you enter, and the filter will discard messages received after that expiration time.

  • Date Time: #[variable:timestamp]

Expires in: 30000

  • Date Time: #[payload.createdAt]

Expires in: 30000

``