Configure Enterprise Search to Include Access-Control-Allow-Origin in Response to API Calls

[TonyWRobinson]

Hi. We are building an in-house client application (in Angular) that will invoke the enterprise search sources and sources/search APIs directly.

However, we have to configure the Enterprise Search server to allow requests from the domain/hostname where our application is hosted. Does anyone know how to add an Access-Control-Allow-Origin header to these API responses?

[JasonStoltz (Jason Stoltzfus)]

Hey Tony, are you certain you need those headers? I was under the impression that our Search API was open already.

[TonyWRobinson]

Yeah, when we are running locally, we have an Angular proxy file that will do a rewrite to avoid the CORS issue. But once the application is deployed, the browser on our laptops is loading the application from where it's hosted, the application makes a call to the API, and then the response that goes back to the browser comes from the Workplace Search API's host and not the host to which the original request (to load the application) was placed. This causes a CORS error and we never get our data back.

We tried working with rproxy.conf and rewrite.conf for our apache server to address this, but, in the end it proved to be easier to have our application talk to an API we've already got running in our environment and have that API invoke the Workplace Search APIs.

In this setup, Chrome on the user's PC requests the application UI from its host, the UI talks to the host of the intermediating API (which is already set up to address CORS), that API makes the calls to Workplace Search and sends the response back to the intermediating (abstraction layer) API, which is then able to send the result back to the UI application, which sends a response to Chrome on the user's browser from the host to which the request was originally submitted.

I do think it all seems a bit more complicated than it should be, but this was the only way we could get it to work.