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 Filters 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 Required Value

    Display Name

    Yes

    A unique name for your message processor.

    Config Reference

    Yes

    Use the name of the global element you created above.

    Operation

    Yes

    Filter by ip

    Regex

    No

    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 Required Value

    name

    Yes

    A unique name for your element.

    doc:name

    Yes

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

  6. Place a filters: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.

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

    Field Required Value

    config-ref

    Yes

    Use the name of the global element you created above.

    regex

    No

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

    doc:name

    Yes

    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 can 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 are 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 yyyy-MM-ddThh:mm:ssZ format, and an expiration time in milliseconds. (Earlier in the flow, you need to name and define this variable so that it extracts the date and time information from your message’s metadata.) The expiration time calculates based on the timestamp extracted from the message, and the filter discards 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 yyyy-MM-ddThh:mm:ssZ format, and an expiration time in milliseconds. The expiration time calculates from the precise date and time you enter, and the filter discards messages received after that expiration time.

  • Date Time:
    #[variable:timestamp]

Expires in: 30000

  • Date Time:
    #[payload.createdAt]

Expires in: 30000