We have a rule that adds a unique UUID to any user that is logging in for the first time:
function(user, context, callback) {
var request = require('request@2.56.0');
var uuid = require('uuid@2.0.1');
user.app_metadata = user.app_metadata || {};
if (!user.app_metadata.uuid) {
updateUuid();
} else {
callback(null, user, context);
}
function updateUuid() {
var newUuid = uuid.v4();
request({
url: auth0.baseUrl + '/users',
headers: {
Authorization: 'Bearer ' + auth0.accessToken
},
qs: {
search_engine: 'v2',
q: 'app_metadata.uuid:"' + newUuid + '"'
}
},
function(err, response, body) {
if (err) return callback(err);
if (response.statusCode !== 200) return callback(new Error(body));
var data = JSON.parse(body);
if (data.length === 0) {
user.app_metadata.uuid = newUuid;
user.app_metadata.given_name = user.given_name;
user.app_metadata.family_name = user.family_name;
auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
.then(function() {
user.uuid = newUuid;
// context.idToken.uuid = newUuid; // somehow this stopped working, too
callback(null, user, context);
})
.catch(function(err) {
callback(err);
});
} else {
console.log("UUID " + newUuid + " already exists. Trying another one.");
// The new UUID already exists, try again
updateUuid();
}
}
);
}
}
On line 6, we could determine whether the current user is a new user or had already logged in before (thus having been assigned a uuid already). So the rule only assigned uuid to new users.
This had been working for months, until suddenly it stopped working sometime last week. What we discovered through debugging is that for existing users who had already been assigned with uuid, when doing renewAuth (silent authentication) the user.app_metadata would sometimes become missing and an identical user.metadata object would appear instead. This is unexpected as such behaviour is not documented in ‘Manage Metadata with Rules’ at all. Note that the key change (from app_metadata to metadata) usually happens from the 2nd or 3rd renewAuth request.
Time of the rule behaviour change might have coincided with us testing/installing the ‘Auth0 Authorization’ extension. However, even after disabling the extension, the behaviour did not revert. So we not not really sure whether the added Extension is the cause.