Does Lock 10 additionalSignUpFields overwrite user_metadata added in pre-registration hook

Help
, ,
1

I have an app where I would like to:

  1. Require a couple of additional fields at signup.
  2. Call a pre-registration hook that searches a legacy user database (non-Auth0) and adds to user_metadata based on results of the old database.

However, when I fire the pre-registration hook, and get a successful response - I can verify the validity of the user_metadata object before supplying to Auth0 - it seems the fields coming from Lock are the only user_metadata fields that get added.

I am following the guide for this extensibility point, and my cb looks like cb(null, response) where response is:

response.user = {
  user_metadata: { /* ... */ },
  app_metadata: { /* ... */ }
}

I can verify that app_metadata makes it to my user’s profile. But user_metadata gets overwritten it seems. Is this expected behavior?

2

I have reproduced the behavior you described and I’m currently reviewing it further to verify if this is expected or not. Will let you know as soon as I additional information.

3

I reviewed the situation and this is incorrect behavior; I already reported the situation internally and it’s being tracked in our backlog, however, I can’t provide you with a definitive timeline for when it will be addressed.

As a workaround you should be able to implement similar functionality from within a rule, although, you would need to keep track of additional flags for performance reasons given rules execute for each authentication transaction.

For example, you could perform the following steps in a rule:

  1. Check for the presence of a truthy flag in app_metadata that indicates if user metadata has been already initialized.
  2. If the flag exists and it’s truthy, return from the rule without additional processing, if not move to the next step.
  3. Obtain the user metadata from your legacy database and update the user with the merged set of user metadata.
  4. Set a flag to true in app_metadata to signal that user metadata has been initialized for this user.
4

Hi @jmangelo.
Thank you for looking into this. Ok, I figured this was the case, hooks being still in beta, relatively new feature. I have implemented a rule in the meantime, similar to what you describe. Though, instead of a truthy flag, I am only calling the database on the first login, i.e., signup. Through context.stats.loginsCount. It seems to do the trick.
Thanks again!
Zach

5

Hi @jmangelo.
Thank you for looking into this. Ok, I figured this was the case, hooks being still in beta, relatively new feature. I have implemented a rule in the meantime, similar to what you describe. Though, instead of a truthy flag, I am only calling the database on the first login, i.e., signup. Through context.stats.loginsCount. It seems to do the trick.
Thanks again!
Zach

6

Yeah, any mechanism that allows you to bypass processing after initializing metadata for the first time is fine.

7

Great,
I’ve updated my code to your specs. Setting a flag in app_metadata actually suits my use case better than a first time login check.
Also, please do let me know when this is scheduled to be patched. If there is a github issue, I’d be curious to follow along on the progress. Thanks.
zach

8

Great,
I’ve updated my code to your specs. Setting a flag in app_metadata actually suits my use case better than a first time login check.
Also, please do let me know when this is scheduled to be patched. If there is a github issue, I’d be curious to follow along on the progress. Thanks.
zach

9

I’ll keep that in mind, it’s not a public repository so there’s no visible way for you to track it directly.