description
This article describes how to configure v2 API proxy settings

Proxy Settings

Introduction

To configure the Proxy settings for a v2 API:

Log in to your APIM Console
Select APIs from the left nav
Select your API
Under the Proxy section of the inner left nav, select from the following:

Entrypoints

To configure the API entrypoints:

Select Entrypoints from the inner left nav

Configure v2 API entrypoints
- Edit your Context-path or create a new one via Add context-path
- Toggle Enable virtual hosts ON or OFF
Click Save

CORS

CORS is a mechanism that allows resources on a web page to be requested from another domain. To configure CORS for your API:

Select CORS from the inner left nav

Configure CORS
Set the following parameters:
- Enable CORS: Toggle to ON to enable CORS.
- Access-Control-Allow-Origin: Define a URI that can access the resource. Enter * to allow all requests, regardless of origin.
{% hint style="danger" %} A value of * is not recommended for production environments. By allowing cross-origin requests, a server may inadvertently expose sensitive information to unauthorized parties. For example, if a server includes sensitive data in a response that is accessible via CORS, an attacker could use a malicious website to extract that data. {% endhint %}
- Access-Control-Allow-Methods: Select the method(s) allowed when accessing the resource, which is used in response to a preflight request: GET, DELETE, PATCH, POST, PUT, OPTIONS, TRACE, and/or HEAD.
- Access-Control-Allow-Headers: Select the HTTP header(s) that can be used when making the actual request, in response to a preflight request. Typically, your request header will include Access-Control-Request-Headers, which relies on the CORS configuration to allow its values.
- Access-Control-Allow-Credentials: Toggle ON or OFF to indicate whether the response to the request can be exposed when the credentials flag is true.
- Max Age: Specify how long (in seconds) the results of a preflight request can be cached. This is optional, and a value of -1 indicates it is disabled.
- Access-Control-Expose-Headers: Define a list of headers that browsers are allowed to access.
- Run policies for preflight requests: Toggle ON for the API Gateway to execute policies for preflight-requests. By default, this is not enabled.
Click Save

{% hint style="info" %} Troubleshooting CORS

All requests rejected because of CORS issues will generate logs that you can view in the Analytics section of your API logs.

{% endhint %}

Deployments

Deployments is where you can choose to use sharding tags sharding tags to control where your API is deployed. To configure sharding tags for your API:

Select Deployments from the inner left nav

Configure sharding tags
From the Sharding tags drop-down menu, choose one or more sharding tags
Click Save

Response templates

Response templates are used to override the default values sent in response to consumer calls to an API. Response template overrides are triggered by error keys, which are specific to policies. Responses can be templatized if the errors raised during the request/response phase(s) are associated with overridable policy keys. Each response template defines the new values to be returned for one or more status codes when the template is triggered.

Prerequisites

Prior to defining a response template, verify:

Which policies have been applied to the API. This can be viewed in the API's plan.
Which error keys can be overridden per policy associated with your API.

Below are the policy error keys that you can override by configuring response templates:

Key	Policy
`API_KEY_MISSING`	API key
`API_KEY_INVALID`	API key
`QUOTA_TOO_MANY_REQUESTS`	Rate limiting
`RATE_LIMIT_TOO_MANY_REQUESTS`	Rate limiting
`REQUEST_CONTENT_LIMIT_TOO_LARGE`	Request content limit
`REQUEST_CONTENT_LIMIT_LENGTH_REQUIRED`	Request content limit
`REQUEST_TIMEOUT`	Mock, Callout HTTP, Request validation
`REQUEST_VALIDATION_INVALID`	Request validation
`RESOURCE_FILTERING_METHOD_NOT_ALLOWED`	Resource filtering
`RBAC_INVALID_USER_ROLES`	Role-based access control
`RESOURCE_FILTERING_FORBIDDEN`	Resource filtering
`RBAC_FORBIDDEN`	Role-based access control
`RBAC_NO_USER_ROLE`	Role-based access control
`OAUTH2_MISSING_SERVER`	OAuth2
`OAUTH2_MISSING_HEADER`	OAuth2
`OAUTH2_MISSING_ACCESS_TOKEN`	OAuth2
`OAUTH2_INVALID_ACCESS_TOKEN`	OAuth2
`OAUTH2_INSUFFICIENT_SCOPE`	OAuth2
`OAUTH2_INVALID_SERVER_RESPONSE`	OAuth2
`OAUTH2_SERVER_UNAVAILABLE`	OAuth2
`HTTP_SIGNATURE_INVALID_SIGNATURE`	HTTP Signature
`JWT_MISSING_TOKEN`	JWT
`JWT_INVALID_TOKEN`	JWT
`JSON_INVALID_PAYLOAD`	JSON validation
`JSON_INVALID_FORMAT`	JSON validation
`JSON_INVALID_RESPONSE_PAYLOAD`	JSON validation
`JSON_INVALID_RESPONSE_FORMAT`	JSON validation
`GATEWAY_INVALID_REQUEST`	All
`GATEWAY_INVALID_RESPONSE`	All
`GATEWAY_OAUTH2_ACCESS_DENIED`	All
`GATEWAY_OAUTH2_SERVER_ERROR`	All
`GATEWAY_OAUTH2_INVALID_CLIENT`	All
`GATEWAY_MISSING_SECURITY_PROVIDER`	All
`GATEWAY_PLAN_UNRESOLVABLE`	All
`GATEWAY_POLICY_INTERNAL_ERROR`	All

Create a response template

When creating response templates, you can define:

Multiple templates for one API (for multiple policies and/or multiple error keys sent by the same policy)
Multiple template definitions for the same error key in a single template (for different content types or status codes)

To configure a response template:

Select Response Templates from the inner left nav
Click on the Add new Response Template button
Customize the Create a new Response Template form

Configure a new response template
- Template key: Choose the template key via the Template key drop-down.
- Accept header to match: Specify the requests header that should trigger use of the response template. The default value is */*. To send the template override values only for JSON or XML requests, specify JSON or XML.
- Status code: Specify the status code that to send to the API consumer via the Status code drop-down.
- Specify the override values to send to the API consumer. These can either be:
  - One or more HTTP headers to include in the response
  - A response template body
Click Create

Properties

Properties are read-only during the Gateway's execution of an API transaction. They can be accessed from within flows using Gravitee's Expression Language (EL) and the #api.properties statement. To configure properties:

To configure API properties:

Select Properties from the inner left nav

Add API properties
To add hardcoded properties, either:
- Click Add property and enter property definitions one at a time as a key-value pair
- Click Import and enter property definitions as a list in <key>=<value> format

Encryption

{% hint style="warning" %} Encrypted values can be used by API policies, but encrypted data should be used with care. APIM Gateway will automatically decrypt these values. {% endhint %}

To encrypt a hardcoded API property value:

Reset the default secret key in gravitee.yml. The secret must be 32 bytes in length.

# Encrypt API properties using this secret:
api:
  properties:
    encryption:
         secret: vvLJ4Q8Khvv9tm2tIPdkGEdmgKUruAL6
 to provide the best security available.

Enable the Encrypt toggle when adding a property via Add property. Once you click Save, you can no longer edit, modify, or view the value.

Dynamic properties

To configure dynamic properties:

Click the Manage dynamically button and define the configuration

Configure dynamic properties
- Toggle Enabled to ON
- Schedule: A cron expression to schedule the health check
- HTTP Method: The HTTP method that invokes the endpoint
- URL: The target from which to fetch dynamic properties
- Request Headers: The HTTP headers to add to the request fetching properties
- Request body: The HTTP body content to add to the request fetching properties
- (Optional) Transformation (JOLT specification): If the HTTP service doesn’t return the expected output, edit the JOLT transformation accordingly
- Toggle Use system proxy ON to use the system proxy configured in APIM installation
Click Save

After the first call, the resultant property is added to the list of global properties, where its value is continuously updated according to the cron schedule specified.

{% hint style="info" %} Key-value pairs can also be maintained using a dictionary, e.g., if this information is stored independently of the API creation process or applies to multiple APIs. {% endhint %}

Resources

Some policies support the addition of resources, which can be used for actions such as authentication and schema registry validation. After you create resources, you will be able to reference them when designing policies. Policies that support resources include:


Basic Authentication	Specify an LDAP Authentication Provider resource and/or an Inline Authentication Provider resource to authenticate users in memory
Cache	Specify a cache resource via the Cache or Cache Redis resources
HTTP Signature Generate HTTP Signature	Specify your HTTP Authentication Provider resource
OAuth2	Specify a Generic OAuth2 Authorization Server resource or a Gravitee AM Authorization Server resource
OpenID Connect Userinfo	Specify a Keycloak Adapter resource to use Keycloack as your OpenID Connect resource
AVRO to JSON AVRO to Protobuf Protobuf to JSON	Specify your Confluent Schema Registry to retrieve serialization and deserialization schemas from a Confluent Schema registry

{% hint style="info" %} Global resources are available to all flows associated with the Gateway API, but are not available to other Gateway APIs. {% endhint %}

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

general-proxy-settings.md

general-proxy-settings.md

Proxy Settings

Introduction

Entrypoints

CORS

Deployments

Response templates

Prerequisites

Create a response template

Properties

Encryption

Dynamic properties

Resources

Files

general-proxy-settings.md

Latest commit

History

general-proxy-settings.md

File metadata and controls

Proxy Settings

Introduction

Entrypoints

CORS

Deployments

Response templates

Prerequisites

Create a response template

Properties

Encryption

Dynamic properties

Resources