Hide Forgot
Description of problem: ebay-cors-filter has not received updates in the last 3 years, being the latest commit d86da0e on 31 Jul 2013 Upstream maintainer is not working anymore for eBay and the project is currently dead. Please consider moving to a maintained library
Juan, do you know of any other existing project/library which we could use instead?
There are alternatives. Take into account that this was introduced in order to allow use of the API from JavaScript applications downloaded from other servers, mostly third party UI plugins, and that it is completely disabled by default. As this doesn't seem to be the future of the oVirt architecture I'd rather consider leaving it as it is, or removing it completely.
Vojtech, do we still need ebay-cors-filter? If so, then we should find some live alternative ...
As Juan mentioned, CORS [1] is necessary when a web application hosted on non-Engine origin (protocol/domain/port) wishes to talk with Engine REST API. This is a consequence of Same-Origin Policy [2] enforced by all web browsers. [1] https://en.wikipedia.org/wiki/Cross-origin_resource_sharing [2] https://en.wikipedia.org/wiki/Same-origin_policy CORS support for REST API therefore targets _only_ web applications that are hosted outside Engine origin. One use case is a UI plugin whose HTML/JS files are not served via Engine [3]. However, this won't work in practice, because such plugin won't be able to access `parent.api` object due to Same-Origin Policy (code within iframe cannot access `parent` document). So this use case is not relevant. [3] org.ovirt.engine.ui.frontend.server.gwt.plugin.PluginResourceServlet This is also mentioned in UI plugin docs: " Note that "parent.pluginApi" is subject to Same-Origin Policy, this implies WebAdmin HTML page and plugin host page must be on same origin, which holds true when using UI plugin infrastructure to serve plugin resource files. " Another use case is a custom web application (different origin) that wishes to talk with REST API. In this case, users may decide to explicitly turn on CORS by setting following Engine config options: CORSSupport = true -and- CORSAllowedOrigins = * // dangerous, allow any origin -or- CORSAllowedOrigins = http://one:1234,http://two:8080 Since Engine REST API uses "RESTEasy" Java framework, I suggest to simply replace the outdated eBay CORS filter with: org.jboss.resteasy.plugins.interceptors.CorsFilter so basically solving CORS on "RESTEasy" Java framework level, not on servlet/filter level. This also means dropping org.ebaysf.web:cors-filter:1.0.1 Maven dependency, along with its JBoss module definition.
Thanks for the suggestion Vojtech. The Resteasy CORS support doesn't seem to be very active either: no updates in the last two years. In addition it brings a Resteasy specific dependency, which we have been trying to avoid. As having or not having CORS seems to be of little relevance we aren't doing any effort to change it.
Development has indicated this request is declined. You may appeal this decision by reopening this request.
I agree that depending even more on RESTEasy framework isn't too good. So we can either keep using the eBay CORS filter as today, or roll our own impl. or simply remove CORS support (but this should be clearly communicated and discussed on devel list first).
Just to be clear, my decision is to not change anything: CORS support will continue working, using the existing filter, it won't be removed.