Incompatible with SignalR JS client RRS feed

  • Question

  • Hi guys

    We extensively use SignalR in our rather complex Azure / Web front ended product. We've recently added Application Insights, which is great - but we've noticed AI JS client has stopped SignalR from working.

    We use MVC end points with SignalR hubs self hosted on OWIN web roles (for scalability). Thinking this might be some specific issue without infrastructure, today I span up a vanilla MVC anonymous web project and SignalR hosted in a vanila ASP.NET with no components and OWIN providing the hosting (with CORS enabled, AllowAll). All very light and vanilla.

    As soon as we introduce the AI JS client we seem the same error.

    What's the error?

    Cross domain (CORS) negotiation issues. From the Chrome console; 

    XMLHttpRequest cannot load http://localhost:50882/signalr/hubs/negotiate?clientProtocol=1.5&connectionData=%5B%7B%22name%22%3A%22notificationhub%22%7D%5D&_=1494500138899. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:50435' is therefore not allowed access.

    Looking at the request in Chromes Network tab, it shows an OPTIONS verb connection to the OWIN server, with a response lacking any Access-Control-Allow-Origin in the header.

    Without the AI JS client code, all we see is a GET request to the OWIN server, with a valid response including the Access-Control-Allow-Origin.

    The question is; without the AI JS, is the OPTIONS call being performed by SignalR? I can't see any evidence for it in Fiddler or the Chrome network tab, so I have to assume either it's not, or it's not designed to be captured under CORS specifications.

    Whichever, OWIN self hosting CorsMiddleware doesn't seem to be able to handle an OPTIONS request - in my view that's secondary to AI JS component high jacking the AJAX negotiation from SignalR.

    VDI for the win!

    Thursday, May 11, 2017 11:01 AM

All replies

  • Further tests show that without the AI JS the OPTIONS verb is not used during SignalR JS negotiations to the OWIN client. OPTIONS is only used when the AI JS is added to the page.

    VDI for the win!

    Thursday, May 11, 2017 11:47 AM
  • So after taking a look through the ai.js from the MS server, I found various undocumented configuration settings. Setting disableAjaxTracking resolves the problem, but is rather a big hammer. I'd prefer to maintain ajax tracking, but just not perform tracking for specified URLs. I've already tried using a telemetry intializer to prevent tracking for signalr based requests, to no avail.

    I'll continue to reverse engineer the MS code since I'm not getting any other help O_O.

    Tuesday, May 16, 2017 10:30 AM
  • So the fix is to set disableCorrelationHeaders: true, for example;

    var appInsights = window.appInsights || function (config) {
                    function r(config) { t[config] = function () { var i = arguments; t.queue.push(function () { t[config].apply(t, i) }) } } var t = { config: config }, u = document, e = window, o = "script", s = u.createElement(o), i, f; s.src = config.url || ""; u.getElementsByTagName(o)[0].parentNode.appendChild(s); try { t.cookie = u.cookie } catch (h) { } for (t.queue = [], i = ["Event", "Exception", "Metric", "PageView", "Trace", "Dependency"]; i.length;) r("track" + i.pop()); return r("setAuthenticatedUserContext"), r("clearAuthenticatedUserContext"), config.disableExceptionTracking || (i = "onerror", r("_" + i), f = e[i], e[i] = function (config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t["_" + i](config, r, u, e, o), s }), t
                    instrumentationKey: "myKey",
                    disableCorrelationHeaders: true
    Apparently this setting used to be true by default until a February push by MS, when it was changed to false by default - thereby breaking our service. Well done Microsoft.

    VDI for the win!

    Thursday, May 18, 2017 1:17 PM