Creating a new user in the dashboard doesn't populate the name from email anymore?

Hi,

Our application is encountering issues when new users are trying to log-in for the first time.
We are using the auth0.net library.

The reason is that we are expecting the FullName user info to be provided, but for some reason it comes back empty for new users.

The users are created manually via Auth0 UI.
Not long ago, creating a user without a name wasn’t an issue since it would be populated with the email address on first login, but it seems it’s no longer the case.

So was this recently changed? If yes, what’s the reason for this change?

Thank you

Hi @Geoffrey-CA,

I’m not sure when or why this changed, but I can confirm I am seeing the same behaviour.

To be honest, plugging the email address in the top level name field never made any sense to me, given we have no ability to change that field once it is set. We started managing our own first and last name attributes under user_metadata.

Cheers,
Mark

Thanks for your answer @markd,

I agree that the behaviour didn’t really make sense, but the change is bringing backward-compatibility issues.

Going ahead, is the new behaviour going to be kept or do we expect the old one to be restored?

Thanks!

I wasn’t very helpful, but always happy to help! :slight_smile:

I understand what you mean … I hadn’t noticed the change until you mentioned it, and I don’t recall seeing any change notifications (I could have missed something of course). Rather unhelpful when people are relying on a given field!

Hopefully someone from Auth0 can chime in on future plans for user.name, as well as user.given_name, user.family_name, user.nickname. I’ve never understood the point of nickname (usually set equal to username is there is a username, otherwise set to the local part of the email address), and the other name attributes are likewise not editable.

1 Like

I’ve noticed a similar issue with parameters passed to callbacks, where used to be an email, now we’re getting some internal auth0 identifier :confused:

We are seeing the same thing. Something changed. What’s the workaround?

Work around:

  1. Create the rule below
  2. Modify app code to use the equivalent attributes from user_metadata
function (user, context, callback) {
 user.user_metadata = user.user_metadata || {};
 user.user_metadata.email = user.email;
 var emailcomponents = user.email.split(‘@’);
 user.user_metadata.name = user.email;
 user.user_metadata.nickname = emailcomponents[0];

 auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
   .then(function(){
       callback(null, user, context);
   })
   .catch(function(err){
       callback(err);
   });
}

Hi everyone. Thanks for reporting this, we’ve found the issue that is causing this behavioral change and a fix is on the way.

I’d suggest the following workaround for now:

function (user, context, callback) {
  // set default values for name and nickname
  user.name = user.name || user.email || "";
  if (!user.nickname) {
    user.nickname  = user.email ? user.email.split('@')[0] : user.name;
  }

  callback(null, user, context);
}

The above rule won’t permanently write the values in the user profile, but it modifies the claims that applications get in the ID Token or in the user profile from the /userinfo endpoint.

2 Likes

Hi again people. The fix is now live, so new users created from now on will have a default name and nickname assigned.

Note that we are not modifying previously created users so if you create a user that does not have one of these properties assigned and you need these properties in place you should delete and recreate the user.
[EDIT]: we reverted a change, so that users will be assigned a default name/nickname on the next login. Moving forward we will ensure that this values are always assigned upon user creation, for greater consistency.

1 Like

This seems like a pretty big change in behavior that is causing us a bit of an issue.

We imported all of our users last month using the import extension. Previously, when a user had reset their password to gain control of the new auth0 account their nickname and name were set. Now, without them set, they are met with a 500 in our django-social-auth apps as ‘nickname’ is a key field missing.

On the user who reported this issue I tried deleting and recreating his account via the import tool, but neither ‘name’ or ‘nickname’ are fields that the tool will accept and pass on to auth0.

(added to this, it seems now we need to audit all of our users for anyone missing these fields for manual intervention)

Any chance that whatever changed can be reverted??

and now that we know what to look for in logs it seems we first hit this issue on 1/17 and has impacted quite a few of our users…

Hi @cshields.

Did you try the rule above to add the missing claims in the response to the application?

We’ve put the rule in place. You might need to change docs for the import tool as all users imported will be broken by default given this behavior.

Cheers

Hi again @cshields.
When you say “all users imported will be broken by default given this behavior”, do you mean those who were previously imported and now won’t have the name/nickname on the first login?

I’m speaking of new users as well.

From my test, “nickname” is not a field that the json importer looks for, so a new user imported using that tool will be missing a nickname and, in our case, would not work without the rule addition.

1 Like

Thanks @cshields. That makes a lot of sense.

I’m relaying this great feedback to the engineering team.

2 Likes

Hi @cshields and everyone else. Just wanted to let you know that we’ve reverted to the previous behavior where a default nickname/name will be assigned on the next login. Thanks for reporting this.

We will be working on ensuring that a nickname and name are always assigned on every instance of user creation (including users import) so that everyone can get a consistent view of a user profile regardless of whether the user logged in or not.

2 Likes

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