I have heard back that the explicit error is this:

Access to fetch at ‘https://api2-eu-west-1.almostinsided.com/v2/topics?q=optimization’ from origin ‘XXXX.zendesk.com’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

I see this article on CORS restriction but I don’t think this applies to us. 

Any insight would be appreciated. 

Hi @alexandra.culler  so without knowing much about your integration it looks like you’re trying to use Javascript (via an xmlhttprequest) to make API calls to pull in data to Zendesk? If so then you might want to just rethink this solution a bit as performing these kinds of requests via front end JS would lead to the exposure of your access token, key and secret - meaning that anyone who could access your ZD application could in theory gain access to your community data via the API which would most likely be an unacceptable security risk.

To get around this you could perhaps develop some sort of middleware application - basically something that sits in between ZD and the API, that does the authentication security via the server side, takes passed in search queries, makes the search API calls and then makes the data available via a JSON response. These search could then be loaded into ZD and displayed as search results that way instead - nice and secure 

@tom.shaddock What if there is no way to create a middle application? Can’t we send a request via javascript at all? Any help would be much appreciated!

@tom.shaddock and @josipjanzic - I am not sure who marked that initial response as the answer to my post, but it does not help us. Marina has asked a follow-up question. She is the developer at Lotus Themes who is facing this problem. 

Hi @marina.belova, the API authentication is currently built for machine-to-machine server side communication. So there is no way at the moment to make API calls directly from the browser on behalf of the user. Calling the API from the browser would mean that the API credentials (id + secret) will be leaked to your zendesk users, and anyone with those credentials will gain admin access to the community platform (eg: create/delete content and users).

As Tom mentioned, the only solution I see at the moment is to have a backend application that will handle the authentication and proxy the search requests from the frontend.

It might be possible to add our embeddable widget into the application that you’re working on, it has built-in search support. Would that be an option for you?

Hi, I’m Alexandra’s colleague. If we placed the embeddable widget on our search results page in Zendesk, would the widget somehow be able to tell what term was searched and produce results associated with that? How would it determine which results to show?

Hi @alissa.wilczynski, @marina.belova  and @alexandra.culler .

I’m Blastoise186, one of the volunteers here. I don’t work for inSided myself and I don’t have access to any Control environments, but I do try to help out where I can.

I had a bit of a hard time finding any Zendesk instances that I know have the inSided embeddable widget installed on, so I did the next best thing and found a page that I know has it in - the Control login pages of both the inSpired Community and my home base. I don’t think anyone will mind, since I’m not attempting to log into Control anyway - I just needed to find somewhere that I could trigger the widget and the login pages were the easiest places to find one.

After playing about with the widget a bit, I managed to find a couple of threads on inSpired that might be helpful to you and I managed to find them both via the widget itself. I’ve linked them below so that you can take a look.

By the looks of things, the widget is designed to try and show content that’s related to what’s on the current page, especially from the page title. I just tried to run a search on a randomly selected Zendesk instance and it unfortunately put a generic Search results - (instance name here) as the page title which would likely throw the widget off track. However, if you’re currently viewing a Zendesk article, then the widget should attempt to run a search of inSided more reliably and bring back something useful. It’s not quite the most ideal method, but unless you can get Zendesk to put something more useful as the page title on search results, I’m not sure the widget can do much else. It is possible to have the widget filter out generic text at least, so that’s better than nothing.

But if you can find a way to reliably put the search query in the page title, that might do the trick. I’d probably recommend asking Zendesk about that as I don’t know how that would work - or if it’s even possible to do. But you might get lucky, so it’s worth having a look at that.

On the plus side, the embeddable widget does have its own built-in search feature, which is capable of running searches of the inSided instance directly from the widget inside Zendesk. It might not be a perfect workaround, but I think it may help to get somewhere towards what you’re looking for with a bit less risk and less complications than trying to play with the API.