Disallow Personal Data During Sign Up


User metadata is added in a pre-user registration action in order for the “Disallow Personal Data” to trigger. However, these are not taken into account for the "Disallow Personal Data” option.


The "Disallow Personal Data” functionality can be used only partially during sign-up. In particular, the metadata fields (user_metadata.first, user_metadata.last) would not trigger.

The reason for this is that the user does not yet exist when they complete the signup form, so the profile will not include those metadata fields.

Adding these in a pre-user registration action in order for the “Disallow Personal Data” to trigger will not do much as the Management API updates of the metadata will be performed after the login flow will be finished (this is a design functionality, actions compile all possible metadata updates and are executed at the end of the flow).

To functionality further:

  1. When creating a user using the signup from the Universal Login, the benefits of enabling the “Disallow Personal Data” option will be available, but they will depend on the fields from the signup form itself. So, for example:
  • If the New Universal Login is used, an email and password will be on the signup form. There will also be the option to require a Username on the “connection,” and that field will appear as well. For example, this is the new universal login signup form in a test tenant:

The “Disallow Personal Data” will trigger in this case depending on those added fields:

  1. If the password contains “exampleUsername” (the username)
  2. If the password contains the initial part of the email “thisisanexample”
  3. In this case since there is no user_metadata yet (first and last), those will not trigger even if you try and add them in the pre-user registration action, for the reasons explained previously.

If Classic Universal Login is used, there will be the option to add “additionalSignupFields” with Lock. It would look like something like this:

NOTE: There are 2 additional fields added at the end, “name” and “first”. In this case, the use case will work since the fields are added to the form and validation is performed. So, for example, looking at the sample form above, a password including “first” will not work.

However, this would force the use of Classic instead of New Universal Login, so we recommend reading the differences highlighted in Universal Login vs. Classic Login beforehand.

So, the current possibilities are:

  1. Use Classic Universal Login and add additional fields so the form includes the fields that will be stored in the users’ metadata directly.
  2. Consider disabling auto-signup in the form and provide an alternative way to create users.