Auth0 Home Blog Docs

Hidden sign up fields to add user metadata

user-metadata
custom-fields
#1

Hi everyone,

I would like to add a role to some of my users using a hidden additional signup field. The signup field should be hidden as I don’t want users to be able to view or change it.
I followed the documentation. https://auth0.com/docs/libraries/lock/v11/configuration

It seems however as if the user metadata in my Auth0 database is not updated with the role.
After signing up with additional hidden signup fields the user-metadata is still an empty json.

what’s happening on the Auth0 Dashboard in Userdetails:
user_metadata:
{}

what I want to happen on the Auth0 Dashboard in Userdetails:
{ “role” : “special user” }

Thanks!

#2

Hey there @astrid, this may actually be a better fit for a rule. Do you have a list of users you would like to have this special identifier? I would love to find out more about your use case. Please let me know if you have any questions!

#4

Hello there @astrid, I was hoping to follow up and see if you had any additional details you could share on this subject. Please let me know if you have any questions.

#5

Hi,

I’m having the same issue. I want to pass the language through a hidden field to the user_metadata. I have added the additional signup field to the lock, but it does not seem to work as expected. Is this feature faulty at the moment?

Our users can determine their language on our site and we want this to become the language set in the user_metadata, so the context language is not what we need. We also don’t want to ask the user twice, once on our site and once on Auth0. A rule is not likely to work for this case either.

#6

Hey @alexandru.lesi can I get a HAR file of the Signup transaction so we can get a better idea of what is going on in the posed situation? Thanks!

#7

Hi @James.Morrison, here’s the HAR file. We pass on the language to the webAuth.authorize(). We then have a lock in our hosted page login template containing the following:

additionalSignUpFields: [{
type: “hidden”,
name: “locale”,
value: config.extraParams.language
}]

We are able to set the lock language successfully, so the value gets passed on to this step correctly. It just looks like it does not get passed on further as a hidden field to the user_metadata.

1 Like
#9

After working with Support @alexandru.lesi we weren’t able to make use of the HAR file you sent due to it being malformed. Instead of leveraging value we would recommend using the prefill option as described in the documentation below to pass along the desired hidden data attribute. Please let me know if this helps in your quest. Thanks!

#10

Hi @James.Morrison, thank you for your suggestion. Unfortunately it does not work. I have tried the following:

additionalSignUpFields: [{
type: ‘hidden’,
name: ‘locale’,
prefill: config.extraParams.language
}],

and

additionalSignUpFields: [{
type: ‘hidden’,
name: ‘locale’
}],
prefill: { locale: config.extraParams.language }

But I still get nothing in the metadata. On the other hand, if I change the signup field to not be hidden:

additionalSignUpFields: [{
name: ‘locale’,
placeholder: config.extraParams.language
}]

Then the field gets filled in just fine and the value gets written to the user_metadata. This is just to confirm that I am getting an input for the field and that the signup fields in itself seem to forward data just fine, just not as hidden fields.
I feel like I have looked at the documentation quite a bit and I have tried out all variations I could think of. At this point do you think it possible that I might have just stumbled on a bug? Is there anything else you can suggest me?
Thanks!
Alex

#11

Hey @alexandru.lesi, when using the type: hidden fields, how come you aren’t leveraging placeholder in that circumstance as well? Can we give it a shot with placeholder apart of that work flow to see if we get a different outcome. Thanks in advance!

#12

Adding the placeholder makes the field visible instead of hidden. The very name to me signals a value that should be filled in a visible field by default - I did not expect it to be related to hidden fields. Either way we need to keep the field hidden so we can’t use this field.

#13

Hey I still haven’t been able to figure these hidden fields out yet. I see the topic will be closed in a day so I’m making another post to confirm that I still need support. Is there anything else you can suggest me to try?

#14

Hi @alexandru.lesi, I apologize for the delay and wanted let you know I will be working to figure out the next forward steps on this today. In the mean time I’ve removed the automatic topic closing timer until we can get you a more robust answer.

#15

After speaking more about this with our team @alexandru.lesi, we feel that one way to move forward on this is to make POST of the desired hidden field data after the user creation via a Management API post. I have included a link to to our Management API docs below that talks a bit about this below. Please let me know if this helps you in your journey.

closed #16

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