All Products
Search
Document Center

API Gateway:CORS plug-ins

Last Updated:Jan 12, 2024

This topic provides a configuration example about a cross-origin resource sharing (CORS) plug-in.

For more information about CORS, see Implement CORS in API Gateway.

Configurations

You can configure your plug-in in JSON or YAML format. Both provide the same schema. You can also convert your configurations from JSON to YAML or vice versa by using a conversion tool. The following sample code provides a configuration template in YAML.

---
allowOrigins: api.foo.com,api2.foo.com,*.foo.com    # The allowed origins. Separate origins with commas (,). Default value: *.
allowMethods: GET,POST,PUT                # The allowed HTTP methods. Separate methods with commas (,).
allowHeaders: X-Ca-RequestId            # The allowed request headers. Separate headers with commas (,).
exposeHeaders: X-RC1,X-RC2              # The headers that can be exposed to the XMLHttpRequest object. Separate headers with commas (,).
allowCredentials: true                    # Controls whether cookies are allowed.
maxAge: 172800
Note
  • If you use the system assigned public second-level domain name to call an API to which a CORS plug-in is bound, you can make your call only in the production environment. When you use a public second-level domain name to call an API in the test or pre-release environment, the X-Ca-Stage parameter is required in the request header to specify the environment. However, the browser does not include the X-Ca-Stage parameter when sending an options request. As a result, the API cannot be requested in the specified environment, and the plug-in does not take effect.

  • If the API is published in a test environment, you can bind a test domain name to deliver cross-domain requests.