2.7.1 Event post produces wrong URL about js-client-sdk

[eli-darkly]

Can I see the code where you initialize your client? It looks to me like options.baseUrl and options.eventsUrl are being set to non-string values. (Edited to add: and also the environment ID - the first parameter to initialize. Both of the URLs you mentioned are constructed as follows: eventsUrl + "/events/bulk/" + environment.)

On the other question: the package that's published on NPM includes minified code. If you're not using NPM, I think your best bet would be to just pull the 2.6.0 tag from Github and build it with npm run build:min.

[18steps]

The initialization part of the code was fine in terms of the values we provided, but we had some other issues; "ReferenceError: exports is not defined" (ldclient.min/index.js:16), "ReferenceError: LDClient is not defined" (in our startup.js).

Fixed it by using the require1k library:

• Remove the script import we had
<script src="/bower_components/ldclient.min/index.js"></script>

• Load our startup script with
<script src="/node_modules/require1k/require1k.min.js" data-main="../src/app/startup"></script>

• And at the top of it, define
window.LDClient = require('../bower_components/ldclient.min/index');

[18steps]

Nevermind, it's still not working when deployed. Same error as before:

404 Not found on a POST to

https://ourdomainname.com/function%20()%20%7B%20[native%20code]%20%7D/events/bulk/function%20n(r)%7Bvar%20o=new%20XMLHttpRequest;return%20o.open(%22POST%22,e+%22/events/bulk/%22+n,!t),h(o),o.setRequestHeader(%22Content-Type%22,%22application/json%22),o.setRequestHeader(%22X-LaunchDarkly-Event-Schema%22,%223%22),t%7C%7C(o.addEventListener(%22load%22,function()%7B400%3C=o.status&&s(o.status)&&r?n(!1).send(u):e(function(e){var%20n={status:e.status},t=e.getResponseHeader(%22Date%22);if(t){var%20r=Date.parse(t);r&&(n.serverTime=r)}return%20n}(o))}),r&&o.addEventListener(%22error%22,function(){n(!1).send(u)})),o}

In the bundled and deployed code, we have this function to arrange the initialization

function initFeatureFlags(oidcUser, jsonConfig, callback) {
  let environmentId = jsonConfig.LaunchDarkly.ClientSideId;
  const user = {
    firstName: oidcUser.profile.given_name,
    lastName: oidcUser.profile.family_name,
    key: oidcUser.profile.preferred_username,
    custom: {
      // ...
    }
  }
    , ldclient = LDClient.initialize(environmentId, user, {
    bootstrap: "localStorage"
  });
  ldclient.on("ready", ()=>{
      window.featureFlagClient = ldclient;
      window.featureFlagClient.allFlags();
      callback()
    }
  )
}

Which for me when called and debugged uses the values:

oidcUser = {
  id_token: 'eyJ0e...',
  session_state: '9h4H3...',
  access_token: 'eyJ0e...',
  token_type: 'Bearer',
  scope: 'openid ...',
  profile: {
    sid: '3e7af3...',
    sub: '8cd24e...',
    auth_time: 1539861230,
    idp: 'Ouridpvalue',
    name: 'Mylastname, Andfirstname',
    preferred_username: '[email protected]',
    amr: ['external'],
    family_name: 'Mylastname',
    given_name: 'Andfirstname',
  },
  expires_at: 1539870652,
};

user = {
  firstName: "Andfirstname",
  lastName: "Mylastname",
  key: "[email protected]",
  custom: { /* just a single [key]: boolean */ }
}

environmentId = '5a1eb...';

[eli-darkly]

So - you're not passing any custom values at all for those URL properties. In that case I have absolutely no idea how the LD client is ending up with functions where there should be strings. Looking at the code, I just don't see how it is possible. I mean, here is where it's setting the base URL for events, and here is where it's constructing the full URL that it posts to. It should be pretty straightforward.

Of the two function objects that have somehow ended up in your URL, the first one - which should be the base URL from my first link - just says "native code", so who knows; the second one looks like a minified version of the createRequest function from my second link. I am completely bewildered as to how the latter could have been picked up by the URL-building expression, especially considering that that function isn't even in scope when the URL is built.

I can't say I've ever seen anything like this.

[louis-launchdarkly]

Closing this as we have had no update from the requester since late 2018.