1

I'm trying to integrate Azure Insights telemetry with our SPA and trying to add authenticated user tracing. For this, after logging in, I call ReactAI.ai().setAuthenticatedUserContext(user_id). I can see the user_id on that specific trace, but not on subsequent ones. If I grab the session id in that trace, I can reconstitute the user journey, but would ideally like to not go through the extra step of figuring out the session id.

marius-O
  • 395
  • 3
  • 15

1 Answers1

1

The full signature of the method would be:

setAuthenticatedUserContext(authenticatedUserId: string, accountId?: string, storeInCookie = false)

You would need to set storeInCookie to true to make sure UserId is preserved across traces.

This cookie was marked as non-essential upon cookies review as per the new cookie laws and could not be an on-by-default cookie. I think you'd need "Cookie statement" on the site if you'd drop this.

Dmitry Matveev
  • 2,563
  • 11
  • 16
  • But `storeInCookie` is NOT necessary if you have `setAuthenticatedUserContext()` on every page e.g. a base layout page. Correct? – Don Cheadle May 05 '19 at 00:32
  • I'd also like to add... this is just a JavaScript/client-side call to App Insights. Where should it go in the JS? Inside tag, before any other JS? And would you still need to track Auth Id's server-side if you already have this JS? – Don Cheadle May 05 '19 at 00:43
  • If you set auth id on every page, most of correlation should be good, maybe, some exceptions for async AJAX calls that were not attributed to a certain page or happened before the auth user id was set. You can make this call at any place before `trackPageView()` is called by AI snippet (so, you can amend the AI snippet itself). If it's a cookie, then it will be possible to perform some user impact analysis on server-side issues as well because frontend server side events will have user id in them. – Dmitry Matveev May 06 '19 at 18:43
  • Dmitry, I've gathered (not from the docs... the docs really need updates) that using this JS only sets `Auth Id` on `Page View` telemetry... but NOT guaranteed on `Dependency`, or `Request` etc. others. Is that correct/expected? – Don Cheadle May 10 '19 at 21:43
  • This does sound unexpected to me - if it's stored into the cookie as per the third parameter of the call, I'd expect it to be respected for any telemetry going out from that browser session. If it does not work - you can have your own Telemetry Initializer in JS SDK to assign auth user ID to the events, either by reading from the cookie or directly: https://github.com/Microsoft/ApplicationInsights-JS/blob/master/API-reference.md#addtelemetryinitializer – Dmitry Matveev May 11 '19 at 01:31
  • Thanks Dmitry! OK but if we *dont* pass the 3rd parameter, to avoid Cookie Statement requirement, then the `setAuthenticatedUserContext` JS *only* sets `Auth Id` for `Page View` telemetry correct? I'd like to confirm that first of all.... And 2nd, if that's correct, then how else *should* we get `Auth Id` set on the other telemetry events? such as `Dependency` and `Request` – Don Cheadle May 13 '19 at 04:04
  • Yep, that sounds right. No cookie - no transfer to server or between sessions even in the same browser. If you have an alternative way to infer actual user identity in the server side code, you can add this information right to the `dependency` and `request` items via [Telemetry Initializers on server side](https://learn.microsoft.com/en-us/azure/azure-monitor/app/api-filtering-sampling#add-properties-itelemetryinitializer). – Dmitry Matveev May 14 '19 at 01:15