Storing given_name, family_name in root

Help
1

I’m trying to collect and store given_name and family_name on the sign-up screen. My configuration is below and successfully causes the fields to show:

      additionalSignUpFields: [
          {
            name: "given_name",
            placeholder: "first name",
            storage: "root"
          },
          {
            name: "family_name",
            placeholder: "last name",
            storage: "root"
          }]

However, when a user is created, the data is saved in the user_metadata area instead of the root, which I have clearly specified according to the docs (Lock Configuration Options). What am I doing wrong?

2

Good morning,

The additional signup fields will always be stored in the metadata, regardless how you name them.

You will need to assign them to the user’s standard claims via Rule .

3

Is the documentation just wrong then? The docs are very clear that given_name and family_name can be stored in the root here:

https://auth0.com/docs/libraries/lock/v11/configuration#additionalsignupfields-array-

If you want to save the value of the attribute in the root of your profile, use storage: 'root' . Only a subset of values can be stored this way. The list of attributes that can be added to your root profile is here. By default, every additional sign up field is stored inside the user_metadata object.

1 Like
4

I’m also having this issue. I literally copied the example from Lock Configuration Options

i.e.

var options = {
  additionalSignUpFields: [{
    name: "name",
    storage: "root"
  }]
};

…and name is still appearing in user_metadata only.

Please confirm if the documentation is wrong, or if this is a bug.

5

I also have the same issue - documentation says we can store these fields in the root, but “storage: ‘root’” just doesn’t work.

6

Been battling this for weeks, this is what I’ve come up with:

  • additionalSignUpFields will always store in the user_metadata, even if the name of the field matches a standardised root claim.

  • You CAN add these claims in a Post-Registration Action, using something like the example below, but the Post-Registration Actions are run asynchonously - so you have zero guarantee that the call to the management API will complete before the auth server redirects you back to your app.

exports.onExecutePostUserRegistration = async (event) => {
    const { clientDomain, clientID, clientSecret } = event.secrets;
    const ManagementClient = require('auth0').ManagementClient;
    var management = new ManagementClient({
        domain: clientDomain,
        clientId: clientID,
        clientSecret: clientSecret,
    });

    management.updateUser(
        { id : event.user.user_id}, 
        { "given_name": event.user.user_metadata.first_name, "family_name": event.user.user_metadata.last_name}
    );
}

  • A Pre-Registration Action runs synchronously but does not allow you to modify the root user claims, only metadata. You also cannot use the method above because there is no user stored at this stage (you have no ID).

  • You can create a custom login form that does allow you to store whatever root fields you want at registration, but you have to use a custom template, which loses a lot of the power of Universal/Lock. Things like adding social login and MFA become more complex to add.

  • You could use additionalSignUpFields, add the custom fields to the metadata, add the metadata to the idToken via a Post-Login Action, then in your app collapse all the profile info down to one flat object for local use :man_shrugging:

@karen1 (gonna tag @konrad.sopala too as he’s a forum legend) there is a hell of a lot of people on the forum begging for an easy solution to this, for quite a while now. It is such a standard thing to ask for Given & Family Name in a signup form. Several solutions:

  • Make Post-Registration Hook synchronous.
  • Parse additionalSignUpFields for root claims and add only those to the root profile.
  • Add another option to the Lock config eg: rootSignUpFields that only allows things like name, DOB, etc.
  • Allow editing of the user object (beyond metadata) in a Pre-Registration Action.

But we really do need a solution. The point of the service is to simplify authentication and signup - if we have to backflip through flaming hoops to add first & last name to a user at registration then it’s kinda defeating the purpose…

9 Likes
7

Do we have a solution for this?