Relative fetch or XHR in a UI-Less Outlook add-in on Windows

Question

I am making an Outlook add-in with UI-Less LaunchEvent-based parts. In order to run on Windows, I have to use Outlook's Javascript runtime, so I have to make do without window or document.

At some point I have to fetch some data from the add-in's server. I tried using both Fetch and XHR to no avail.

Naive example with Fetch:

fetch("/JsonData").then(r => r.json());

However, this results in a TypeError: Network request failed. Additionally, I am using Wireshark, and I see no request sent to the server.

Note that:

• I am in a Javascript-only runtime, so no window or document
• I have no control over the server root URL so I cannot hardcode it
• I have tried several tricks based on Javascript's stacktrace to get the current JS file URL, without success (best I got was code as the file URL using this snippet)

How can I use a relative URL to retrieve data from my server? This is such a common thing to do that I am sure there is a way to do it, just not the way I am doing it.

EDIT It appears that marking the add-in for debugging allows Fetch to work as expected with the exact same statement as above, even when no debugger is attached. This means enabling add-in debbugging changes something in the runtime that allows Fetch to target the add-in's own server.

Answer 1

First of all, when making calls outside the domain your add-in is hosted in, you need to specify those domains in your add-in's manifest:

<AppDomains>
    <AppDomain>http://siteone.com/</AppDomain>
    <AppDomain>https://sitetwo.com/</AppDomain>
</AppDomains>

Second, the same-origin policy enforced by the browser prevents a script loaded from one domain from getting or manipulating properties of a webpage from another domain. This means that, by default, the domain of a requested URL must be the same as the domain of the current webpage. For example, this policy will prevent a webpage in one domain from making XmlHttpRequest web-service calls to a domain other than the one where it is hosted.

Because Office Add-ins are hosted in a browser control, the same-origin policy applies to script running in their web pages as well.

The same-origin policy can be an unnecessary handicap in many situations, such as when a web application hosts content and APIs across multiple subdomains. There are a few common techniques for securely overcoming same-origin policy enforcement. The Addressing same-origin policy limitations in Office Add-ins article can only provide the briefest introduction to some of them.