How to send a user attribute from Signup page to app metadata

Help
,
1

Hi Community,
@rueben.tiow @dan.woda @dawid.matuszczyk

I have a bit of questions as below regarding the user metadata and app metadata.

How can we make the user attributes in user profile not editable for the user?

Our understanding is that if we manage to place that attribute to the app-metadata then the user will not be able to edit it.
Based upon my scenario I have added an additional field namely “usertype” which is a dropdown kind of fields to the signup page and i want it to be non editable to the user.

By default this is going to the user metadata(attributes in user metadata can be read/written by the user) which is just the opposite of our requirement. My question is
How and where is user profile should we send this usertype field of the signup page so that it becomes not editable to the user?

Also please correct my understanding in case it isn’t.

Thanks and Regards,
Aafreen Khan

3

Hi @Aafreen_Khan,

The user’s attributes should not be editable by the users themselves unless you have a mechanism to allow them to update their own user attributes.

Can you please clarify how you are allowing the user to update their user attributes?

Thanks,
Rueben

1 Like
4

Hi @rueben.tiow

Thanks a lot for your prompt response.

Actually our project is still in the pre-implementation phase so we are exploring all the possibilities and vulnerabilities to be covered
I am aware of the fact that for the user to be able to edit the user metadata attributes we have to rendered it to them through a form(not aware how exactly its done).
Again the question stands is it alright/safe for the signup attributes to sit in the user metadata if we are not having any form/mechanism to render it to the user for editing?
And given we don’t have a mechanism to edit user metadata attributes does there remains a need to transfer these attributes to app metadata?
Actually i have a rule where i am able to send the selected signup field from the user metadata to the app metadata but i am not able to remove this attribute from the user metadata even after using delete operations on it.
Here is the code below for the same:

 function usernameAttribute(user, context, callback) {
  
  if (!user.app_metadata.username) {
 
    user.app_metadata.username = user.app_metadata.username || user.username;
  }


  if (user.user_metadata && user.user_metadata.user_type) {
    
    user.app_metadata.user_type = user.user_metadata.user_type;


     user.user_metadata.user_type = null;
  }


  auth0.users
    .updateAppMetadata(user.user_id, user.app_metadata)
    .then(function () {

      callback(null, user, context);
    })
    .catch(function (err) {
      callback(err);
    });
}

Please let me know if it still requires some clarifications from my end.

Thanks and Regards,
Aafreen Khan

5

Hi @Aafreen_Khan,

Thanks for following up.

Yes, this is completely fine and encouraged.

There is no need to duplicate the information in your app_metadata if you have already added the signup attributes to the user metadata.

You need to update the attribute with null using 'auth0.users.updateUserMetadata()` so that the data persists on the user’s profile.

Thanks,
Rueben

6

Hi @rueben.tiow

Thanks so much Rueben that’s a lot of help.
Can you please also let me know how we can create that mechanism/form to render attributes in user metadata to be able to be edited by the users.
If available, can you share the details and the auth0 doc link if any.

Thanks and Regards,
Aafreen Khan

7

Hi @Aafreen_Khan,

For this, you will need to call the Management API’s update a user endpoint when the user has made changes to their user metadata attributes.

Now, let me clarify that you have 2 options for getting an access token to call the Management API.

The first involves passing the audience=(https://{tenant}.auth0.com/api/v2/) parameter in the login request so the returning access token grants the user permission to update their user metadata. (Reference: Call Your API Using the Authorization Code Flow).

The second involves making a client credentials grant flow request to the Management API to get an access token.

Here are some additional resources:

Please let me know if you have any questions.

Thanks,
Rueben

8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.