The setAppMetadata
api is not working with PreUserRegistration Actions for Passwordless Connections. I have tested this API numerous times (as well as setUserMetadata
) with functional Action code and everything else is working as expected except these APIs. Invoking them does nothing, as the new user and app metadata objects are both empty after registration is completed.
It looks like other users have reported this issue (most recently in this post, and the support engineer pointed out that “Pre-User Registration Action triggers for both Database and Passwordless connections”. ) I have found that to be true, as everything else in my PreUserRegistration Action is working as expected.
I’m calling this api as specified by the documentation (api.user.setAppMetadata("some", "value")
) and there are no errors when I view Real-time Webtask Logs for the action (as I mentioned all other code is working).
Please help, as I believe this is a bug/issue.
Thanks,
Hi @myconode,
Welcome to the Auth0 Community!
Just to gather more information on the issue, could you clarify if this is happening for Passwordless SMS, email, or both?
Thanks,
Rueben
Hi Rueben, thank you for your reply! I haven’t tested SMS yet, only email. Happy to provide any more details as well if that is helpful.
I did some more testing and believe this is a UI bug with the User Management dashboard. I set up a PostUserRegistration Action and have successfully printed out the event.user
object containing the metadata set in the PreUserRegistration Action.
Hi @myconode,
Thank you for the responses.
I have just verified the behavior you observed and confirmed that the Pre-User Registration Action fails to persist the data set from the api.user.setAppMetadata()
method.
Because of this, I am going to pass this bug report to our Engineering teams to take a look at this issue.
As a workaround for the moment, I recommend using a Post-Login Action to set the app metadata for the user the first time they log in. Take note that users are automatically signed in after they sign up, which means we can leverage this behavior to set the app_metadata on the first login.
For example:
/**
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
*/
exports.onExecutePostLogin = async (event, api) => {
if(event.stats.logins_count === 1){
api.user.setUserMetadata("favorite_color", "blue");
}
};
Please let me know if you have any questions.
Cheers,
Rueben
1 Like
Thanks for your response Rueben. I did confirm that this API is working in my testing by setting user and app metadata in a PreUserRegistration Action and verifying the data retrieval in a PostUserRegistration Action, though the data does not appear in the User Management dashboard.
Can you please confirm you’re observing this behavior as well, and if so log another bug? Also, since this has affected other users in the past, can you please mark this issue as solved when the fix is deployed & confirmed by the engineering team?
Thank you,
Hi @myconode,
What you have observed is the same as my observations. Essentially, that is what is meant by my previous message that the post login action is not persisting the data set from the api.user.setAppMetadata()
method.
I can confirm this behavior and recommend using a Post-Login Action as a workaround.
Sure, I can leave this topic unsolved until our engineering teams have resolved this issue.
Thanks,
Rueben
1 Like
Just ran into this bug too. ETA on a fix?
Example use-case for why this makes PreUserRegistration completely unusable for us: we use it to guard errant user creations for invite-only scenarios by calling our API. Then we try to persist that data on the user (if they’re let in) through the rest of the post-login actions.
In that sense, we can give the user immediate feedback on the login page, if they aren’t able to be let in.
If we wait to do any of that until post-login, the user gets created, and the only user feedback we have is api.access.deny - hardly ideal since it results in a redirect. Needless to say, we then have users stuck in intermittent states that we have to manage. Much better to not have them exist at all.
And calling our API twice (once in PreReg to guard, and once in post-login to retrieve and persist the data) is just silly.
I also tried persisting the data in the api.cache and that didn’t work either. It looks like for connections (based on some logging I did), the PreReg workflow runs on /passwordless/start and not /passwordless/verify … so it looks like after the workflow is shutdown after /passwordless/start, all the context is lost.
I wonder if that’s the bug.
1 Like