This page and its children relate to Repose filters and services. You can select and customize Repose filters and services to suit your application.
Standard filter order
The filters in Repose are compiled byte-codes that have configuration files that provide functionality between the client and the origin service. These filters often interact with each other, so the order in which you list them in the system model is important. You can use a filter to gather information from third-party servers that will then pass information to other filters. For example, you can use the Client Authentication filter to determine a user's role before it is used by the API Validation filter.
Although not all filters have strict dependencies, using the standard default order prevents you from injecting unnecessary bugs into your deployment. Some deployments might require a different order from the standard order. Additionally, not all filters are required for each deployment. You define which filters and services are deployed within your system model.
Note: This table does not contain the full list of filters.
|SLF4J HTTP Logging||Place the Simple Logging Facade for Java (SLF4J) HTTP Logging filter at the top of the filter chain. |
|CORS Filter||Place the CORS filter near the top to handle Preflight Requests.|
|Forwarded Protocol||Place the Forwarded Protocol filter near the top of your filter chain.|
|Add Header||Place this filter before any filters that need to receive the added static header in the request.|
|URL Extractor to Header||Place this filter before any filters that need to receive the added dynamic header in the request.|
|Place the Normalization filters near the top. These filters clean the request to prevent unexpected request headers and content. |
|Header Translation||Place the Header Translation filter before filters that need headers translated.|
|Keystone v2 Basic Authentication||Place the Keystone v2 Basic Authentication filter before the authentication and authorization filters so that they can process the X-Auth-Token header.|
|Keystone v2||Place the Keystone v2 filter before the other identity filters. This filter sets the X-Roles, X-PP-User, and X-PP-Groups headers.|
|OpenStack Identity v3||Place the OpenStack Identity filter before the other identity filters. This filter sets the X-Roles, X-PP-User, and X-PP-Groups headers.|
|Client Authentication||Place the Client Authentication filter before the identity filters. This filter sets the X-Roles, X-PP-User, and X-PP-Groups headers.|
|Header User||Place the user filters next. These filters provide alternative methods of setting the X-PP-User and X-PP-Groups headers.|
|Client Authorization||Place the Client Authorization filter next to validate whether the user has access to the requested endpoint. |
|Rackspace Auth User||Place the Rackspace Auth User filter before the Rate Limiting filter. This filter removes the username from the body and sets it in the X-PP-User header for rate limiting.|
|Highly Efficient Record Processor (HERP) ||Place the HERP filter after the authentication and authorization filters.|
|Delegation Response Processor (DeRP)||Place the DeRP filter after the HERP filter.|
|Rate Limiting||Place the Rate Limiting filter next. This filter uses the URI, X-PP-User, and X-PP-Groups to establish rate limits. |
|Versioning||Place the Versioning filter before the Validation filter to finalize the URI.|
|Compression||Place the Compression filter before anything that looks at the request body. |
|API (WADL/XSD) Validation||Place the API (WADL/XSD) Validation filter after the Compression filter. API (WADL/XSD) Validation filter uses X-Roles to validate requests.|
|Simple RBAC||Place the Simple RBAC filter after the Compression filter.|
|Translation||Place these filters last in the filter chain. They do not need to precede any other filters.|
|Content Type Stripper|
You may use two instances of this filter.
- Place it at the top of the filter chain if you plan use the filter for responses.
- Place it at the bottom of the filter chain if you plan to use the the filter for requests.
Filter names, XSDs, examples, and descriptions
The following tables include the filter and service names that are used in the system model, the path to the XML schemas, and example configuration files. The filters and services are divided into categories that define their most basic function. Click the links for more detailed information about each component.
Request-response modification filters
Rate limiting filter