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
|Filter name|| <filter-name>||XML schema definition||Example configuration||Description|
As of Repose v126.96.36.199, this filter is no longer available.
Acting as a reverse proxy, this filter can be configured to use an identity endpoint to authenticate an HTTP request before the request is passed to the origin server. The Client Authentication filter supports the OpenStack Identity Service authentication scheme.
As of Repose v188.8.131.52, this filter is no longer available.
This filter can be configured to validate that a client request is allowed. If the request is allowed, it proceeds through the filter chain, on to the origin service. If the request is not allowed, the request will be denied with an HTTP 500 - Internal Server Error response.
|Content Normalization||content-normalization||normalization-configuration.xsd||content-normalization.cfg.xml||Allows normalization of the headers and media-type of the request.|
|Default Router ||default-router||-||default-router-context.xml||Scans the destinations of a service domain and add the first destination that has default="true" specified. This feature was deprecated in Repose version v2.4 and removed in v184.108.40.206|
|Distributed Datastore||dist-datastore||dist-datastore-configuration.xsd||dist-datastore.cfg.xml||As of Repose v3.0, this filter is no longer available. Use the Datastore Service instead; see Distributed Datastore as a Service. If you have not upgraded to v3.0 and are still using the Distributed Datastore filter, place it at the top of the filter chain. This filter intercepts datastore-specific http requests, which the other filters do not need to process.|
|HTTP Logging||http-logging||http-logging-configuration.xsd||http-logging-cfg.xml||The HTTP Logging Component allows logging of information in HTTP requests that are sent to Repose and responses from Repose.|
|Root Context Router||-||-||-||The root context router applies only to Repose instances running in the JEE 6 Application Container;see ROOT.war Deployment. This filter has been deprecated in Repose version 2.0. In prior versions of Repose, the root context router allows a user to use the ROOT.war deployment to filter requests that will be forwarded to deployed applications on the same application server.|
|IP Identity||ip-identity||ip-identity-configuration.xsd||ip-identity.cfg.xml||Enables Repose to introspect a request's source IP and set the X-PP-User and X-PP-Groups headers as needed.|
|Rackspace Auth 1.1 Content||content-identity-auth|| ||content-identity-auth-1-1.cfg.xml|| |
|Rackspace Cloud Auth 1.1|| || || || |
|Replicated Datastore||replicated-datastore|| ||root-context-router.cfg.xml||As of Repose v2.13.1, this filter is no longer available.|