Customizing the preflow policies

By default, whenever an API is called, a series of policies, called the preflow policies, are invoked prior to the policy assembly configured in the API definition. However, by using a global policy you can, if required, fully customize the behavior of these policies, controlling if and when they are invoked, and with what customization

Before you begin

Default preflow policies

The following preflow policies are invoked by default:

  • cors: handles cross-origin resource sharing (CORS) requests for the API; invoked if CORS is enabled in the API definition settings.
  • wsdl: handles WSDL requests.
  • html-page: for a GraphQL API, if the GraphQL editor option is enabled, returns the GraphQL HTML page.
  • client-identification: examines the API key credentials that are carried in the API request and matches the API Plan through which the target API is made available to the client.
  • ratelimit: enforces the rate limit scheme that is configured for the matching API Plan. When the rate limit is reached, the request is rejected.
  • security: performs the authentication and authorization checks that are required by the target API and operation. if the security requirement is not fulfilled, the request is rejected.

Configuring a global policy to customize the preflow policies

To customize the preflow policies, complete the following steps:

  1. Add the following property to the info: section of your global policy .yaml file:
    mode: mode_type
    Where mode_type is one of the following options:
    • after-builtin - this means that your preflow policies are applied after the default preflow policies.
    • before-builtin - this means that your preflow policies are applied before the default preflow policies.
    • full-custom - this means that you must explicitly add the preflow policies to the assembly of your global policy. You can, however, remove, reposition, or replace any of the preflow policies as required.
  2. Configure the policies in your global policy assembly as required.
    An after-builtin global policy example:
    global-policy: 1.0.0
info:
  name: foo-example
  title: foo-example
  version: 2.0.0
  mode: after-builtin
gateways:
  - datapower-api-gateway
assembly:
  execute:
    - set-variable:
        version: 2.0.0
        title: set-variable
        actions:
          - set: message.headers.X-Flexible-Preflow
            value: 'Hello reboot global policy 1 on catalog 1 this policy will be executed after all default builtins'
            type: string
    A before-builtin global policy example:
    global-policy: 1.0.0
info:
  name: foo-example
  title: foo-example
  version: 2.0.0
  mode: before-builtin
gateways:
  - datapower-api-gateway
assembly:
  execute:
    - set-variable:
        version: 2.0.0
        title: set-variable
        actions:
          - set: message.headers.X-Flexible-Preflow
            value: 'Hello reboot global policy 1 on catalog 1 this policy will be executed before all default builtin policies'
            type: string
    A full-custom global policy example:
    global-policy: 1.0.0
info:
  name: preflow-4-actions
  title: preflow-4-actions
  version: 2.0.0
  mode: full-custom
gateways:
  - datapower-api-gateway
assembly:
  execute:
    - cors:
        version: 2.0.0
        title: cors-in-preflow
    - wsdl:
        title: default-wsdl
    - html-page:
        title: html-page-in-preflow
        output: message
        version: 2.0.0
    - helloworld:
        version: 1.0.0
        title: helloworld
    - client-identification:
        version: 2.0.0
        title: ci-in-preflow
    - ratelimit:
        version: 2.0.0
        title: assembly-rt-in-preflow
        source: plan-default
    - security:
        version: 2.0.0
        title: sec-in-preflow
    - set-variable:
        version: 2.0.0
        title: set-variable
        actions:
          - set: message.headers.X-Flexible-Preflow
            value: 'Hello reboot with 4 actions'
            type: string
  3. Deploy your global policy as a pre-request global policy.