So I've never used ActiveX to make requests before, but I would consider sending this via jQuery.ajax or jQuery.get instead. It's also worth noting that the APIs are REST with JSON not XML. Not sure if there is a Microsoft.JsonHTTP around, but perhaps it has something to do with the interpretation. For example, found this snippet that might help:

Reaching out to some engineers internally to make sure that I've got my hands wrapped around the entirety of your problem.

In short, due to XSS protections, you shouldn't be able to directly call the API from a different origin via JavaScript without running into these problems.

There is no config file that controls this header, rather its baked into the product as a standard security measure.

I'm still looking into this, as it seems weird that this use-case is completely blocked, but thus far what I've read/heard is that you'll need to leverage a proxy of sorts and/or host a resource like a .js file on your community and reference that file in your application. Haven't had a chance to check the last option, but if the resource that is requesting the asset is loaded from the same domain, it might allow this hit to come through. Getting a JS file on your domain, could be as simply as uploading a JS proxy file into an HTML Widget's managed files.

I don't but if you want to test it out, you basically put the implementation you have into a function in a JS file...get an admin to add your JS file to an HTML widget'a managed files...and have them send you the URL for that resource.

Then all you beed to do in your HTML is include that JS file and call the function. This used to be a work around for some domain security back in the day, so hoping this still works.

The biggest gap we have here is browser authority. The suggestion above wasn't to use server-side Javascript, but rather, upload a JS file as a managed file on your Jive Community in an HTML widget. This might allow the JS class to execute the desired calls, but this was a stretch. In general, to make this solution work without a proxy in-between to get rid of CORS limitations, the solution will be very limited.

I wish I had a better answer for you, but given the design pattern at play here, we need to find a way to get a proxy between the HTML not on your Jive domain and the API. Have you considered writing a Jive App in Canvas mode for this feature, Jive Apps have a built in proxy to the APIs and can be hosted off property, but must conform to the Jive Apps Framework.

Just to understand it right: Your users always access the portal, there is a search box and there they enter eg "tax". Then the portlet creates the HTTPS requests, connects to Jive directly and formats the results. So the browser does not need to know the Jive URL and it does not connect to Jive for this use case. As the portelt acts as an application proxy there are no CORS, XSS or browser issues.

The portlet may either use a service user to get all results or login on behalf of the current user to query only results which the user can see in Jive.

The user logs in portal. Then you have the 'uid' of the authenticated user. The portet has a Jive admin account and sends the search request (run-as feature) on behalf of the user. It converts Jives Json response to HTML and sends the response to the user.

It the user clicks on a search result it connects to Jive for the 1st time and Jive-SSO should work or one has to login manually or the user did login before and the result is displayed immediately.

Running into the same problem, I was able to getover the problem by specifying the below parameters on AJAX request. Now I can see the response in browser, but not able to handle the response since the javascript is expecting a JSONP response, what JIVE returned was a JSON response

crossDomain: true,

contentType: "application/json",

dataType: 'jsonp',

Is there any there way of handling the response, Appreciate any help around this.