Auth0 Home Blog Docs

Optional sign up field is acting like required field



I have the following configuration for my implementation. For some reason, the affiliate_id field is acting as if it’s required but it shouldn’t be. Any idea what the problem is?

additionalSignUpFields: [
                    name: "given_name",
                    placeholder: "First Name",
                    validator: function (given_name) {
                        return {
                            valid: given_name.length >= 3,
                            hint: "Required"
                    name: "family_name",
                    placeholder: "Last Name",
                    validator: function (family_name) {
                        return {
                            valid: family_name.length >= 3,
                            hint: "Required"
                    name: "affiliate_id",
                    placeholder: "Referred by"


Is there anything I’m missing here? I’ve been through the documentation and according to this configuration, affiliate_id should not be a required field.

I’d appreciate some help with this.


Hey there @imsam67!

Yep looking at your setup everything is fine. family_name and given_name are required but affiliate_id should not be required. I started digging into it with our Developer Support Team.

Will get back to you shortly!


Wanted to followup on that @imsam67!

What’s the version of Lock you’re using?

Here’s the part on additional signup fields from the repo docs:


I’m using version 11.9. Here’s a screen shot of my package.json:


The default validator if none is provided seems to be that the field length is greater than zero (code here).
You can provide a no-op validator instead:

  name: "affiliate_id",
  placeholder: "Referred by",
  validator: () => true

That did the trick in my testing.


Thank you! This definitely solved the issue.

Don’t you think that if validator is omitted, Auth0 Lock should simply assume it’s not a required field? Though your solution fixes the issue and I’m grateful for your help, it does appear to be a band-aid. Don’t you think so?


I understand your point completely (and was surprised by this behavior), but a similar counter-argument could be made that “If I’m putting a custom field in there, I want the user to fill it in!”. :smiley:

In any case, as with many examples in the IT industry, we are stuck with the original decision, at least until a major new version arrives, for backward compatibility.

I’ll send a document PR to clarify the default behavior and this workaround.