launchdarkly / react-client-sdk

LaunchDarkly Client-side SDK for React.js
Other
86 stars 68 forks source link

How to authenticate user? #59

Closed gajus closed 3 years ago

gajus commented 3 years ago

All React SDK examples assume that user ID is known before the application is loaded.

How does one update user ID after they login?

bwoskow-ld commented 3 years ago

Hi @gajus ,

As mentioned in our documentation, you can use the user-related functionality exposed by our JavaScript SDK which underlies the ReactJS SDK. In particular you should read about changing the user context.

Let me know if that fully answers your question.

Cheers, Ben

gajus commented 3 years ago

It is really not obvious... either the docs are off or the API response is not intuitive.

Here is an example:

// An arbitrary ID that we assign to the user for the purpose of syncing with LaunchDarkly.
const launchDarklyId = '0a1ce0c2-a281-4cef-9911-72d6c2e7511e';

const UnrestrictedAppPreload = ({ children }: AppPreloadProps) => {
  const LDClient = useLDClient();

  console.log({user: {
    launchDarklyUser: LDClient?.getUser(),
  }});

  if (LDClient?.identify) {
    LDClient.identify(
      {
        key: launchDarklyId,
      },
    ).then((result) => {
      console.log({login:{
        userAfterLogin: LDClient?.getUser(),
      }});
    });
  }

  return null;
};

export const AppPreload = withLDProvider({
  clientSideID: '[REDACTED]',
})(UnrestrictedAppPreload);

Currently, the output of the above is:

{user:{launchDarklyUser: {anonymous: true, key: '235597f0-62a5-11eb-8409-193bcccb018c'}}}
{login:{userAfterLogin: {key: '0a1ce0c2-a281-4cef-9911-72d6c2e7511e'}}}

so, suppose that's expected... However, if I refresh the page, I get the same response again.

Whereas, I expect:

{user:{launchDarklyUser: {anonymous: false, key: '0a1ce0c2-a281-4cef-9911-72d6c2e7511e'}}}
{login:{userAfterLogin: {key: '0a1ce0c2-a281-4cef-9911-72d6c2e7511e'}}}

How do I make identification persist?

bwoskow-ld commented 3 years ago

Hi @gajus ,

I can see that you've additionally filed a request with our support team. That's good, because this request fits more in line with something that our support team would handle, as opposed to a bug in the SDK code.

For that reason I'm going to close this issue. Our support team is well-equipped to handle it from here on your other ticket.

Cheers, @bwoskow-ld

gajus commented 3 years ago

It would be definitely useful for folks who consume this SDK to know the answer... We figured it out eventually, but it was super unclear and took many ours of experimentation.

bwoskow-ld commented 3 years ago

I'm glad to hear you're worked past your issue!

We're always updating our documentation to improve our content quality and substance. In fact, we even accept third-party contributions to our documentation. If you have a particular change in mind which you want to contribute, we would welcome it.

Otherwise, please share information with our support engineers about what was unclear so that we can bring that information back to our documentation team. Long term, it is a more effective solution to incorporate feedback like this into our documentation rather than referring back to resolved GitHub issues like this one.

Cheers, @bwoskow-ld

gajus commented 3 years ago

Well, long story short, if anyone else comes across this: LD does not handle any user identity persistence. You need to implement session persistency yourself. You have to store the key (and if you are using it) the hash, and all other user attributes.

bwoskow-ld commented 3 years ago

I believe that this should work correctly out of the box if you enable persistence in local storage. Anyways, thanks for the feedback.