Hi Freeman, Thanks for the input. Given that these services are internal and not exposed to be publicly called, I can live with that trade-off.
John > On May 20, 2014, at 6:42 PM, Freeman Fang <[email protected]> wrote: > > Hi, > > If you don't care the possible security whole, you can write a server side > interceptor like > > public class EnableCORSInterceptor extends AbstractPhaseInterceptor<Message> { > > public EnableCORSInterceptor() { > super(Phase.PRE_PROTOCOL); > } > > @Override > public void handleMessage(Message message) throws Fault { > Map<String, List<String>> headers = > Headers.getSetProtocolHeaders(message); > try { > //Access-Control-Allow-Origin:* > Access-Control-Allow-Methods:POST,GET > headers.put("Access-Control-Allow-Origin", Arrays.asList("*")); > headers.put("Access-Control-Allow-Methods", Arrays.asList("POST", > "GET")); > } catch (Exception ce) { > throw new Fault(ce); > } > } > } > > and add it to the server out interceptor chain > －－－－－－－－－－－－－ > Freeman(Yue) Fang > > Red Hat, Inc. > FuseSource is now part of Red Hat > > > >> On 2014-5-21, at 上午3:46, John Dubchak wrote: >> >> Hi, >> >> We have several bundles deployed in our services architecture using SMX >> 5.0.0 (CXF: 2.7.10, Camel: 2.12.3) and now we are starting to integrate HTTP >> and Mobile clients into the mix. However, one issue we are seeing is CORS >> errors based on having not configured any cross-origin headers. Our goal is >> to avoid the requirement of having client applications bundled with our SMX >> fabric to prevent CORS errors. >> >> How can that be accomplished or are there other ways to achieve what we are >> trying to do? >> >> Thanks for any insight and/or help, >> John >
