Feature flags don't work without starting tracking

[andreialecu]

Describe the issue
Feature flags don't work without starting tracking. They don't load.

If I call .reloadFlags() manually, the library throws:

console.js:102 TypeError: Cannot read properties of undefined (reading 'userOS')
    at featureFlags.js:38:26
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (asyncToGenerator.js:3:1)
    at _next (asyncToGenerator.js:22:1)
    at asyncToGenerator.js:27:1
    at new ZoneAwarePromise (zone.js:1425:21)
    at asyncToGenerator.js:19:1
    at FeatureFlags.reloadFlags (featureFlags.js:58:10)
    at API.reloadFlags (index.js:213:85)

Steps to reproduce the issue

tracker = new Tracker({
          ...
          flags: {
            onFlagsLoad: (flags) => {
              console.log('Flags loaded', flags);
            },
          },
        });

• onFlagsLoad is not called.

• call tracker.reloadFlags()

• see error:
  

Expected behavior

We're running into a bit of a chicken and egg issue. We want to enable tracking based on feature flags, but we must start tracking to get the feature flags.

It should be possible to read feature flags without starting tracking.

Screenshots

Error happens here:

OpenReplay Environment

• Tracker version: 12.0.3

[andreialecu]

Related #1903

[andreialecu]

Upon inspecting the source a bit, it seems that userInfo is populated by the REST api call that start() does.

coldStart() does not seem to help.

It doesn't seem necessary for userInfo to be POSTED to /v1/web/feature-flags. It could internally do the same thing start() does and handle that info on the server side.

It would also make more sense from a security perspective, as you can spoof the call and get access to feature-flags you couldn't easily otherwise get access to, by fiddling with userInfo in Chrome Developer Tools for instance.

[nick-delirium]

We're running into a bit of a chicken and egg issue. We want to enable tracking based on feature flags, but we must start tracking to get the feature flags.

For that we have conditionally triggered recordings (that also provide ~30s buffer), which are supported in our cloud and EE offerings.

Also, fetching feature flags require auth token and some parts of user info that are generated once user makes initial connection (which allows us to not keep the session itself in backend state and support high concurrent traffic) and therefore has to be sent with flags request.

It would also make more sense from a security perspective, as you can spoof the call and get access to feature-flags you couldn't easily otherwise get access to, by fiddling with userInfo in Chrome Developer Tools for instance.

Well it's also possible to spoof the network request itself and gain any flags you want :)

If you have any other solutions, we're happy to hear them

[andreialecu]

Well it's also possible to spoof the network request itself and gain any flags you want :)

Indeed, but it’s harder to spoof the location that way. It’s not much of an issue but it seems less than efficient to download and upload that ‘userInfo’ object, considering it’s server built.

How do those conditionally triggered recordings work? Can you point to some documentation, please?

[estradino]

@andreialecu the conditional recording allows you to trigger the capture when certain criteria are met (for example when a user visits pageA or a call to /endpointB is called). The tracker would then trigger and send the last few seconds recorded before the predefined event, then continues recording the entire session.
Conditional recording is only available on our Cloud offering (the dedicated plan) and the self-hosted enterprise edition.