Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

AppInsights and third-party script CORS problem

See original GitHub issue

Not quite sure if it is a bug, more like a question, but maybe a bug…

I have application insights enabled on my app website, and then have a third-party script loaded that communicates with its own website.

The problem is that app insights instruments the global XMLHttpRequest object, and when that script tries to fetch data from its own site it gets CORS error because it’s sent actually from app insights (different origin). This is my understanding of the situation at least, the details are below.

How can I workaround the issue? Can I tell app insights not to instrument the XMLHttpRequest? (I don’t really need it)

To clarify the problem:

<body>
...
<script>
// this instrumetns XMLHttpRequest
const appInsights = new ApplicationInsights({
  config: {
    instrumentationKey: SOM_APPINSIGHTS_INSTRUMENTATIONKEY
  }
});
</script>
</body>

// this fails because XMLHttpRequest is instrumented (CORS error)
<script><script type="text/javascript" src="https://js.hs-scripts.com/XXX.js"></script>
</body>

The Error (in the latest Chrome browser):

Access to XMLHttpRequest at 
'https://api.hubspot.com/livechat-public/v1/message/public?portalId=XXXXXXXX' 
from origin 'http://localhost:3333' has been blocked by CORS policy: 
Request header field traceparent is not allowed by Access-Control-Allow-Headers in preflight response.

(anonymous) @ InstrumentHooks.js:97       <<<<<< this is app insights code
f @ fetchWidgetData.js:78                 <<< this is third-party javascript
loadWidget @ WidgetShell.js:498
(anonymous) @ throttle.js:21
start @ WidgetShell.js:581
v @ startOnceReady.js:55
I @ startOnceReady.js:96
(anonymous) @ startOnceReady.js:111
captureErrors @ ErrorLogger.js:119
b @ startOnceReady.js:110
(anonymous) @ start.js:18
s @ bootstrap:19
(anonymous) @ bootstrap:97
(anonymous) @ conversations-embed.js:1

Issue Analytics

State:
Created a year ago
Comments:7 (2 by maintainers)

Top GitHub Comments

2reactions

MSNevcommented, Oct 4, 2022

Hmm, I’ve not heard of that before…

This

from origin 'http://localhost:3333' has been blocked by CORS policy: 
Request header field traceparent is not allowed by Access-Control-Allow-Headers in preflight response.

is a response from the server and the “presence” of the traceparent header on the request… So that is not caused by the code being intercepted…

There is another config correlationIdCanIncludeCorrelationHeader that you can set to stop the traceparent from being added to “ALL” requests (but the ajax request will still cause a RemoteDepenency event to be sent after the request)…

And also correlationHeaderExcludedDomains which is used to block specific domains (rather than regex pattern) https://github.com/microsoft/ApplicationInsights-JS/blob/master/shared/AppInsightsCommon/src/Util.ts#L374-L384

0reactions

HARVS1789UKcommented, Dec 1, 2022

As @MSNev suggested, the existence of the traceparent HTTP request header (and/or others added by the A.I code possibly?) added to certain fetch requests (as I had manually enabled fetch tracking via disableFetchTracking: false) was causing them to fail CORS checks on the recipient server. For me, this was googleapis.com as part of my Google Firebase based authentication process.

I resolved this by excluding requests to that domain from having tracking headers added via:

correlationHeaderExcludedDomains: ["www.googleapis.com"]

in my A.I config