Thanks Dan. At the risk of hijacking this thread, I assumed it was reasonable to use app_metadata on the user object to store properties that describe something about the user which is never seen by the user and only written/read from server-side code (in this case a flag to preserve state that is written and read from an action script). Are you suggesting that isn’t safe? If so I’m not sure I understand what app_metadata on the user object is for.
How and when app_metadata is (or isn’t) presented to the user is going to depend on your implementation.
For example, it’s common that app_metadata is added to tokens, which could then be read by the user of a client side app, but the user would have no ability to manage its contents as it is in a signed token.
This is outlined here: Understand How Metadata Works in User Profiles
If you have any more questions about this, please create a new topic and tag me.
Is this scheduled to be included in the future? Have the same need.
Thanks for sharing your interest. This feature request has not been scheduled for development.
My team is also interested in the original post request, specifically related to the OP’s number 2:
“Deny a social registration if a user with the same email address already exists. (i.e. enforce unique email addresses)”
Thanks for considering!
Also would like to upvote this, my team would aslo be able to “Deny a social registration”. Hope that this will be included for the future.
I really need a feature like this too.
upon registration, some sort of license key is generated in app_metadata and should be included in the welcome e-mail.
This works for e-mail based accounts, but not for social logins as the pre-registration isn’t triggered., and the post-login happens after the welcome e-mail is send out.
Thank you everyone for sharing additional context. We’ll analyze it at the beginning of next month in collaboration with our product team and potentially will add it to our engineering backlog. Thank you for your understanding!
This would make soooooo much sense to have. Now we have to hack everything into the Post Login flow, making it overly complicated.
Agreed this would be very helpful. We’re trying to limit users to those we manually create in the password database. We can prevent logins, but it doesn’t appear there’s any way to actually stop the user from signing up using a social connection and getting added to the tenant.
Upvote for post-user-registration as well. I expect y’all could probably 2 birds one stone here.
Chiming in here as this feature would also be very useful to me.
What would be really useful to me would be the ability to deny a social registration via an action. As a previous poster said, we’ve worked around this with a post-login action, but this does not stop the account itself from being created.
I worked around that by deleting the just created account on the action the problem is that it does not redirect to the sign up screen with an error.
Our main use case is: “Deny a social registration if a user with the same email address already exists. (i.e. enforce unique email addresses)”
Currently this is implemented with a hacky and overly complex post-login Action (which doesn’t fully work due to another issue.
Enforcing email uniqueness would be less of an issue, if the official account linking extension would support Actions: Allow for account linking with actions - Auth0 Community
I understand that the Auth0 team has their own roadmap and priorities. But it is a bit frustrating that there is no activity for months/years on valid and useful requests from the community.
+1 for this
We have an usecase in an organizational context. We want to reject user-creation when the user tries to log in the first time via enterprise-connection and the related licence is not sufficient.
Current workaround would be to reject login and delete the just created account in the postlogin-action as described by @carlos.trujillo . This feels hacky
@konrad.sopala any update here from the product team?
Hey there @j.krabs !
Let me follow up with the engineering team on that front and get back to you shortly!
Any updates from the engineering team?
Not yet but I think we can expect the answer in the coming days. Will share it with you once I have it
Just got an update from the team.
Work on the user management action triggers is on the roadmap for this year and supporting pre/post creation triggers for social connection will be evaluated and included if possible.