Feature: Provide a short title of your feature request/feedback.
Trigger the Pre User Registration flow for social and other non-database connection types.
Description: Give us some details about your feedback/feature request. Examples, screenshots, videos, etc. are helpful.
For some reason, the Pre User Registration flow does not run for social or other non-database connection types. This makes it impossible to:
- Create a corresponding user in an external database, before the user is registered in Auth0.
- Deny a social registration if a user with the same email address already exists. (i.e. enforce unique email addresses)
- Set a user’s locale/language in metadata for use in email templates.
These are very significant limitations.
Use-case: Tell us what you are building. How would the feedback/feature improve your experience?
If this flow was extended to include social and other connection types, we would be able to use it to accomplish all of the items listed above. Without it, I’m not even sure if Auth0 will work for us.
Hi @gg-dev, thank you for the feedback and detailed use cases!
Hey gg-dev, I understand your issue and upvoted it.
On a sidenote, cause you said auth0 might not work for you:
Since the Login flow is the only hook that triggers regardless of the concrete connection, this is where we put all the logic you described into and abandoned all the other hooks, which are exclusively for database connections.
In concrete this means that for social logins the only option right now is to create the users on login. Once you apply this logic you realize that the same logic can also be applied to database users. That leaves the other registration hooks totally useless once you decide to support social logins.
Thanks for the input @hendrik .
Thanks, we had set up Post Login code, but unfortunately it doesn’t fit our needs (some of which are listed in the OP).
This, together with the other 4 items of feedback that I posted, meant that we were unable to move forward with Auth0.
Thank you for all the feedback and really sorry to hear that Glen!
I’ve also hit this limitation and had to work around it. I ended up doing as @hendrik described - I have “complete user registration” login action which checks a flag in the user’s
app_metadata and if the flag is missing, runs some code (in my case to assign roles and set user metadata based on a custom invitation it retrieves from an API in our systems), then sets the flag in
app_metadata to prevent the same code running a second time. This works, but it feels hacky, and is vulnerable to somebody inadvertently messing with the flag I’ve set in
app_metadata (I also check for
logins_count > 1, but I found the action runs more than once with
logins_count == 1 as I refresh my SPA app page after first login, so testing
logins_count > 1 on it’s own is not a safe way of preventing the code running multiple times).
Thanks for the additional context.
I think this solution makes sense for the time being. Just FYI, users shouldn’t be able to manage any data within app_metadata.
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.