feat: Add Application Insights browser usage telemetry

[BenjaminMichaelis]

Summary

Implements Azure Monitor Application Insights dual-instrumentation per Microsoft's usage analysis docs.

What's added

Browser (client-side)

• New \�ppinsights-manager.js: consent-aware App Insights JS SDK loader
  • Loads SDK from \js.monitor.azure.com\ only after \�nalytics_storage: granted\
  • \disableTelemetry = true\ + explicit \�i_user/\�i_session\ cookie deletion on consent revocation (runs unconditionally — covers returning visitors with stale cookies)
  • Exposes \window.ecsGetAppInsights()\ and \window.ecsGetCorrelationContext()\ for cross-module use
• \consent-manager.js: dispatches \�cs:consent-changed\ CustomEvent; adds \�i_user/\�i_session\ to \clearTrackingCookies()\ for the 'forget me' path

Custom events (code runner lifecycle)

• \ rydotnet-module.js: fires \TryCodeRunnerOpened, \TryCodeRunnerRequested, \TryCodeRunnerCompleted\ custom events; passes W3C \correlationContext\ to the Try SDK for optional E2E trace correlation

Server-side

• \Program.cs: \EnrichWithHttpRequest\ callback sets \�nduser.id\ OTel tag from \NameIdentifier\ claim (stable GUID, non-PII) for authenticated requests
• CSP updated: \js.monitor.azure.com\ in \script-src; \https://*.in.applicationinsights.azure.com\ + dynamic connection string endpoint in \connect-src\

Layout

• _Layout.cshtml: exposes \window.APPLICATIONINSIGHTS_CONNECTION_STRING\ and \window.AUTHENTICATED_USER_ID\ via @Json.Serialize(); includes \�ppinsights-manager.js\

Privacy / GDPR notes

• App Insights connection string in browser is intentional and safe (ingestion-only key)
• \�i_user/\�i_session\ cookies persist only while consent is granted; cleared on every page load for denied-consent users
• \�nduser.id\ uses the stable Identity GUID, not email — privacy policy update needed (separate PR/ticket)

[Copilot]

Pull request overview

Adds Azure Monitor Application Insights browser telemetry to the site, gated by the existing analytics consent flow, and emits custom events around the Try .NET code-runner lifecycle. Server-side, it enriches OTel spans with enduser.id from the authenticated user's NameIdentifier and extends CSP for the AI ingestion endpoints. The layout now exposes the AI connection string and authenticated user id to the page.

Changes:

• New appinsights-manager.js consent-aware loader plus ecs:consent-changed event from consent-manager.js.
• trydotnet-module.js fires TryCodeRunner*/TryCodeRun* custom events and passes a correlation context to the Try .NET SDK.
• Program.cs adds OTel EnrichWithHttpRequest enduser id tagging and CSP entries; _Layout.cshtml exposes APPLICATIONINSIGHTS_CONNECTION_STRING and AUTHENTICATED_USER_ID globals and loads the new script.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
EssentialCSharp.Web/wwwroot/js/trydotnet-module.js	Emits custom AI events around code-runner open/run; forwards correlationContext to Try SDK.
EssentialCSharp.Web/wwwroot/js/consent-manager.js	Dispatches ecs:consent-changed, exposes getConsentState, clears ai_user/ai_session cookies.
EssentialCSharp.Web/wwwroot/js/appinsights-manager.js	New consent-gated App Insights JS SDK loader with auth context and trace id helper.
EssentialCSharp.Web/Views/Shared/_Layout.cshtml	Exposes connection string + authenticated user id globals; loads new manager script.
EssentialCSharp.Web/Program.cs	Adds enduser.id OTel tag and AI-related CSP sources, including endpoint parsed from the connection string.

Comments suppressed due to low confidence (4)

EssentialCSharp.Web/wwwroot/js/trydotnet-module.js:408

• The custom event names are inconsistent: the "Opened" event uses TryCodeRunnerOpened (with "Runner"), but the run lifecycle events use TryCodeRunRequested and TryCodeRunCompleted (without "Runner"). The PR description further refers to these as TryCodeRunnerRequested and TryCodeRunnerCompleted. Pick one prefix (e.g., TryCodeRunner*) and apply it consistently across all three events so dashboards/queries can filter on a common prefix.

        trackTryEvent('TryCodeRunRequested', eventProperties);

        try {
            await withTimeout(session.run(), RUN_TIMEOUT, ERROR_MESSAGES.runTimeout);
            const durationMs = Math.round(performance.now() - startedAt);
            trackTryEvent('TryCodeRunCompleted', { ...eventProperties, success: 'true' }, { durationMs });
        } catch (error) {
            codeRunnerOutput.value = error.message;
            codeRunnerOutputError.value = true;
            const durationMs = Math.round(performance.now() - startedAt);
            trackTryEvent(
                'TryCodeRunCompleted',
                { ...eventProperties, success: 'false', errorType: error?.name ?? 'Error' },
                { durationMs }
            );

EssentialCSharp.Web/wwwroot/js/appinsights-manager.js:190

• getCurrentTraceId() reads appInsights?.context?.telemetryTrace?.traceID. At the time useTryDotNet()/the configuration object is built, App Insights may not yet be initialized (the SDK is loaded asynchronously after consent), so this commonly returns null and correlationContext is set to null in the Try .NET session configuration. Even when AI is initialized, this trace id is captured once at session-init time and not refreshed per run(), so all subsequent runs share the same correlation id (which corresponds to the original page view, not the run). Consider either fetching the trace id lazily at the moment trackTryEvent('TryCodeRunRequested', ...) fires, or generating a new operation id per run.

    function getCurrentTraceId() {
        const traceId = appInsights?.context?.telemetryTrace?.traceID;
        if (typeof traceId === "string" && /^[a-f0-9]{32}$/i.test(traceId)) {
            return traceId.toLowerCase();
        }
        return null;
    }

    window.ecsGetAppInsights = function () {
        return appInsights;
    };

    window.ecsGetCorrelationContext = function () {
        return getCurrentTraceId();
    };

EssentialCSharp.Web/wwwroot/js/appinsights-manager.js:145

• ConsentManager.init() now calls notifyConsentChanged() unconditionally on load, and appinsights-manager.js also calls syncConsentState() directly in its own init(). Depending on script ordering and DOMContentLoaded timing, the appinsights manager can both (a) receive the consent-manager's startup event and (b) run its own syncConsentState, resulting in two concurrent onConsentGranted invocations. The !appInsights guard inside the .then callback prevents double-construction, but two ensureSdkLoaded() chains run in parallel and either both call createAppInsights() (if both .then callbacks resolve before appInsights is set on the first) — there is no synchronization between the two awaited promise resolutions. Consider gating the in-flight grant with a boolean (e.g., isInitializing), or only sync from the event (not directly in init()).

    function onConsentGranted() {
        const connectionString = getConnectionString();
        if (!connectionString) {
            return;
        }

        ensureSdkLoaded()
            .then(() => {
                if (!appInsights) {
                    appInsights = createAppInsights();
                    window.ecsAppInsights = appInsights;
                } else {
                    appInsights.config.disableTelemetry = false;
                    setAuthenticatedContext();
                }
            })
            .catch((error) => {
                console.warn("Application Insights SDK initialization failed:", error);
            });
    }

EssentialCSharp.Web/wwwroot/js/appinsights-manager.js:165

• onConsentRevoked() deletes ai_user/ai_session cookies on every page load when consent is not granted (since syncConsentState() runs on init). The expiration string lacks the SameSite attribute used elsewhere by App Insights when it sets these cookies, and the loop sets domain=${hostname} and domain=.${hostname} only — for an apex domain such as essentialcsharp.com this works, but if the SDK originally wrote the cookie on a parent domain (e.g., user navigated from www. to apex or vice versa), only one of the variants will match. Consider iterating progressively shorter parent domains as consent-manager.clearTrackingCookies() already does, and reuse that helper to avoid duplication.

        const expired = "expires=Thu, 01 Jan 1970 00:00:00 GMT";
        const secure = window.location.protocol === "https:" ? ";Secure" : "";
        const hostname = window.location.hostname;
        ["ai_user", "ai_session"].forEach(function (name) {
            document.cookie = `${name}=;${expired};path=/${secure}`;
            document.cookie = `${name}=;${expired};path=/;domain=${hostname}${secure}`;
            document.cookie = `${name}=;${expired};path=/;domain=.${hostname}${secure}`;
        });

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

EssentialCSharp.Web/wwwroot/js/appinsights-manager.js:152

• window.ecsAppInsights is only assigned the first time an instance is created (inside the if (!appInsights) branch). When consent is revoked and later re-granted, appInsights is reused (else-branch only flips disableTelemetry), which is fine — but if createAppInsights() returns null (e.g., SDK loaded but no connection string at that moment), window.ecsAppInsights will be set to null, and the unconditional assignment overwrites any prior valid instance reference that might have been published elsewhere. Consider only assigning window.ecsAppInsights when appInsights is non-null, or removing this global entirely since window.ecsGetAppInsights() is already the public accessor and exposing both is redundant.

                if (!appInsights) {
                    appInsights = createAppInsights();
                    window.ecsAppInsights = appInsights;
                } else {
                    appInsights.config.disableTelemetry = false;
                    setAuthenticatedContext();
                }

EssentialCSharp.Web/wwwroot/js/appinsights-manager.js:177

• The cookie-clear strings build path=/${secure} without a ; between path=/ and the Secure attribute. Because secure is initialized as ";Secure" (with a leading semicolon) this happens to render correctly today, but the intent is non-obvious and a future edit that changes secure to "Secure" (without leading ;) would silently produce an invalid path=/Secure attribute. Consider including the separator in the template (e.g. path=/;${secure} with secure being just "Secure" or empty) to make the dependency on the leading semicolon explicit.

        const expired = "expires=Thu, 01 Jan 1970 00:00:00 GMT";
        const secure = window.location.protocol === "https:" ? ";Secure" : "";
        const hostname = window.location.hostname;
        ["ai_user", "ai_session"].forEach(function (name) {
            document.cookie = `${name}=;${expired};path=/${secure}`;
            document.cookie = `${name}=;${expired};path=/;domain=${hostname}${secure}`;
            document.cookie = `${name}=;${expired};path=/;domain=.${hostname}${secure}`;
        });

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.