Chapter 5. Advanced APIcast Configuration
This section covers the advanced settings option of 3scale’s API gateway in the staging environment.
5.1. Define a secret token
For security reasons, any request from the 3scale gateway to your API backend contains a header called X-3scale-proxy-secret-token
. You can set the value of this header in Authentication Settings on the Integration page.
Setting the secret token acts as a shared secret between the proxy and your API so that you can block all API requests that do not come from the gateway if you do not want them to. This adds an extra layer of security to protect your public endpoint while you are in the process of setting up your traffic management policies with the sandbox gateway.
Your API backend must have a public resolvable domain for the gateway to work, so anyone who knows your API backend can bypass the credentials checking. This should not be a problem because the API gateway in the staging environment is not meant for production use, but it is always better to have a fence available.
5.2. Credentials
The API credentials within 3scale are always user_key
or app_id/app_key
depending on the authentication mode that you are using (OAuth is not available for the API gateway in the staging environment). However, you might want to use different credential names in your API. In this case, you will need to set custom names for the user_key
if you are using the API key mode:
Or, for the app_id
and app_key
:
For instance, you could rename app_id
to key
if that fits your API better. The gateway will take the name key
and convert it to app_id
before doing the authorization call to the 3scale backend. Note that the new credential name has to be alphanumeric.
You can decide if your API passes credentials in the query string (or body if not a GET) or in the headers.
APIcast normalizes header names when extracting credentials. This means they are case insensitive, and underscores and hyphens are treated equally. For example, if you set the App Key parameter as App_Key
, other values such as app-key
are also accepted as valid app key headers.
5.3. Error messages
Another important element for a full-fledged configuration is to define your own custom error messages.
It is important to note that the 3scale API gateway in the staging environment will do a pass of any error message generated by your API. However, since the management layer of your API is now carried out by the gateway, there are some errors that your API will never see because some requests will be terminated by the gateway.
Following are some of the errors:
- Authentication missing: This error is generated whenever an API request does not contain any credentials. It occurs when users do not add their credentials to an API request.
- Authentication failed: This error is generated whenever an API request does not contain the valid credentials. It can be because the credentials are fake or because the application has been temporarily suspended.
- No match: This error means that the request did not match any mapping rule and therefore no metric is updated. This is not necessarily an error, but it means that either the user is trying random paths or that your mapping rules do not cover legitimate cases.
5.4. Configuration History
Every time you click the Update & Test Staging Configuration button, the current configuration is saved in a JSON file. The staging gateway will pull the latest configuration with each new request. For each environment, staging or production, you can see a history of all the previous configuration files.
Note that it is not possible to automatically roll back to previous versions. Instead a history of all your configuration versions with their associated JSON files is provided. Use these files to check what configuration you had deployed at any point of time. If you want to, you can recreate any deployments manually.
5.5. Debugging
Setting up the gateway configuration is easy, but you may still encounter errors. In such cases, the gateway can return useful debug information to track the error.
To get the debuggging information from APIcast, you must add the following header to the API request: X-3scale-debug: {SERVICE_TOKEN}
with the service token corresponding to the API service that you are reaching to.
When the header is found and the service token is valid, the gateway will add the following information to the response headers:
X-3scale-matched-rules: /v1/word/{word}.json, /v1 X-3scale-credentials: app_key=APP_KEY&app_id=APP_ID X-3scale-usage: usage%5Bversion_1%5D=1&usage%5Bword%5D=1
X-3scale-matched-rules
indicates which mapping rules have been matched for the request in a comma-separated list.
The header X-3scale-credentials
returns the credentials that were passed to 3scale backend.
X-3scale-usage
indicates the usage that was reported to 3scale backend. usage%5Bversion_1%5D=1&usage%5Bword%5D=1
is a URL-encoded usage[version_1]=1&usage[word]=1
and shows that the API request incremented the methods (metrics) version_1
and word
by 1 hit each.
5.6. Path routing
APIcast handles all the API services configured on a 3scale account (or a subset of services, if the APICAST_SERVICES_LIST
environment variable is configured). Normally, APIcast routes the API requests to the appropriate API service based on the hostname of the request, by matching it with the Public Base URL. The first service where the match is found is used for the authorization.
The Path routing feature allows using the same Public Base URL on multiple services and routes the requests using the path of the request. To enable the feature, set the APICAST_PATH_ROUTING
environment variable to true
or 1
. When enabled, APIcast will map the incoming requests to the services based on both hostname and path.
This feature can be used if you want to expose multiple backend services hosted on different domains through one gateway using the same Public Base URL. To achieve this you can configure several API services for each API backend (i.e. Private Base URL) and enable the path routing feature.
For example, you have 3 services configured in the following way:
-
Service A Public Base URL:
api.example.com
Mapping rule:/a
-
Service B Public Base URL:
api2.example.com
Mapping rule:/b
-
Service C Public Base URL:
api.example.com
Mapping rule:/c
If path routing is disabled (APICAST_PATH_ROUTING=false
), all calls to api.example.com
will try to match Service A. So, the calls api.example.com/c
and api.example.com/b
will fail with a "No Mapping Rule matched" error.
If path routing is enabled (APICAST_PATH_ROUTING=true
), the calls will be matched by both host and path. So:
-
api.example.com/a
will be routed to Service A -
api.example.com/c
will be routed to Service C -
api.example.com/b
will fail with "No Mapping Rule matched" error, i.e. it will NOT match Service B, as the Public Base URL does not match.
If path routing is used, you must ensure there is no conflict between the mapping rules in different services that use the same Public Base URL, i.e. each combination of method + path pattern is only used in one service.