Cross-origin resource sharing (CORS) is included with FME Server and is disabled by default. You must manually enable the CORS filter for each web service or web interface applicable. To do this for a particular web application, open its deployment descriptor in a text editor and uncomment the CORS filter directives at the end of the file.
For example, the default location of this file for the Job Submitter service is \FMEServer\Utilities\tomcat\webapps\fmejobsubmitter\WEB-INF\web.xml.
<!-- Cross-Origin Resource Sharing - Filter Configuration
Enabling this filter allows you to control cross-origin requests rather than coping with traditional
browser restrictions.
Uncomment the section below and configure the "init-param" elements that meet your CORS requirements.
CORS Configuration - http://software.dzhuvinov.com/cors-filter-configuration.html
See Also the FME Server Reference Manual
-->
<filter>
<filter-name>CORS</filter-name>
<filter-class>com.thetransactioncompany.cors.CORSFilter</filter-class>
</filter>
By default the CORS filter is configured to be enabled for every possible URI to the web application. This can be adjusted using J2EE filters. (For more information, see the J2EE v2.5 Servlet Specification.)
<filter-mapping>
<filter-name>CORS</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
For a complete CORS filter declaration and mapping example, see the web.xml of the demo CORS application included with the download package.
Note: By default the CORS filter applies a "public access" CORS policy, allowing all cross-site requests (including credentials/cookies). Leaving the CORS Filter at this setting is appropriate for most situations, as the intent of CORS is not to add server security, but to protect the browser, including legitimate JavaScript apps running in it and the user's confidential data, such as cookies.
The CORS filter can be run with no additional configuration in most situations. By default it operates in public mode: It informs the browser that requests from any origin are accepted and that they may include optional credentials such as cookies.
The default CORS behavior can be overridden by adding one or more explicit init-param elements to the filter declaration in the WEB-INF/web.xml descriptor file.
For example, to allow CORS requests from http://example.com only:
<filter>
<filter-name>CORS</filter-name>
<filter-class>com.thetransactioncompany.cors.CORSFilter</filter-class>
<init-param>
<param-name>cors.allowOrigin</param-name>
<param-value>http://safe.com</param-value>
</init-param>
</filter>
For a complete CORS filter declaration, configuration and mapping example, see the web.xml of the demo CORS application included with the download package.
Note: You must restart the web application or server after making CORS configuration changes.
Defaults to true.
If true, generic HTTP requests are allowed to pass through the filter. Else, only valid and accepted CORS requests are allowed.
Defaults to *.
Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included are refused with an HTTP 403 "Forbidden" response. If set to *, any origin is allowed.
Example: Allow any origin:
*
Example: Allow cross-domain requests from the following three origins only:
http://fmeserver.com http://safe.com:8080 https://my.own.net
Defaults to false.
If true, the CORS filter allows requests from any origin that is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name/IP address and optional port number).
Example: If the explicitly allowed origin is http://example.com and subdomains are allowed, all of the following origins are also allowed:
http://www.fmeserver.com
http://secure.fmeserver.com
http://passport.fmeserver.com
These non-matching origins, however, will be denied:
http://www.fmeserver.com:8080
https://foo.fmeserver.com
http://myexample.com
Defaults to "GET, POST, HEAD, OPTIONS".
List of supported HTTP methods. These are advertised through the Access-Control-Allow-Methods header and must also be implemented by the actual CORS web service. Requests for methods not included here are refused by the CORS filter with an HTTP 405 "Method not allowed" response.
Example: Allow only GET cross-origin requests:
GET
Example: Allow the methods for a typical RESTful web service:
GET, POST, HEAD, PUT, DELETE
cors.supportedHeaders {header-list}
Defaults to empty list.
The names of the supported author request headers. These are advertised through the Access-Control-Allow-Headers header.
An author request header is any custom header set by the browser JavaScript application through the XMLHttpRequest.setRequestHeader() method.
Example: Inform the browser that the following author request headers are supported:
Content-Type, X-Requested-With
Defaults to empty list.
List of the response headers other than simple response headers that the browser should expose to the author of the cross-domain request through the XMLHttpRequest.getResponseHeader() method. The CORS filter supplies this information through the Access-Control-Expose-Headers header.
Example: Inform the browser that the following custom headers are safe to be exposed to the script that initiated the cross-domain request:
X-Custom-1, X-Custom-2
Defaults to true.
Indicates whether user credentials, such as cookies, HTTP authentication or client-side certificates, are supported. The CORS filter uses this value in constructing the Access-Control-Allow-Credentials header.
Defaults to -1 (unspecified).
Indicates how long the results of a preflight request can be cached by the web browser, in seconds. If-1, the time is unspecified. This information is passed to the browser via the Access-Control-Max-Age header.
Example: Specify that the browser should cache preflight requests for 1 hour:
3600
Note: You must restart the web application or server after making CORS configuration changes.
See Also