You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there is no easy and direct way to intervene in the authorization flow based on whether the user is new (signup) or not (login).
A user has proposed to verify some property that is not in both situations, but I don't know how reliable it is. Does it work in all circumstances? For all providers? Also, it's not self-evident or something that follows from the documentation. A user a few comments above in the same thread proposed a similar alternative, which ended up not working. As you can see, it is a workaround that is prone to errors.
Allow events to block the authorization flow in some way (return boolean, throw error, etc.).
Extend next-auth to have signup and login as different processes. This would likely involve, but not necessarily be limited to:
3.1. Add a new Signup callback (as requested here).
3.2. Add a new Signup function (as requested here).
The third point is probably the hardest to implement and the one that would add the most complexity. I don't know to what extent it would be wrong since users and programmers actually think of creation and login as different concepts. Still, I think I lean more toward options 1 and 2.
In option 2, the events would end up being essentially the same as the callbacks.
Option 1, on the other hand, would be to add for an event, its corresponding callback that does not exist yet. Which would make the event technically unnecessary.
I wonder if actually "events" was a good abstraction and not just a few more callbacks should have been defined.
Background - Related References
The large number of posts, comments, and upvotes in the login vs signup topic indicate that this is something that users are frequently stumbling upon. Some examples:
It looks like this issue did not receive any activity for 60 days. It will be closed in 7 days if no further activity occurs. If you think your issue is still relevant, commenting will keep it open. Thanks!
Description 📓
Problem
Currently, there is no easy and direct way to intervene in the authorization flow based on whether the user is new (signup) or not (login).
A user has proposed to verify some property that is not in both situations, but I don't know how reliable it is. Does it work in all circumstances? For all providers? Also, it's not self-evident or something that follows from the documentation. A user a few comments above in the same thread proposed a similar alternative, which ended up not working. As you can see, it is a workaround that is prone to errors.
Possible solutions:
3.1. Add a new Signup callback (as requested here).
3.2. Add a new Signup function (as requested here).
The third point is probably the hardest to implement and the one that would add the most complexity. I don't know to what extent it would be wrong since users and programmers actually think of creation and login as different concepts. Still, I think I lean more toward options 1 and 2.
In option 2, the events would end up being essentially the same as the callbacks.
Option 1, on the other hand, would be to add for an event, its corresponding callback that does not exist yet. Which would make the event technically unnecessary.
I wonder if actually "events" was a good abstraction and not just a few more callbacks should have been defined.
Background - Related References
The large number of posts, comments, and upvotes in the login vs signup topic indicate that this is something that users are frequently stumbling upon. Some examples:
How to reproduce ☕️
N/A
Contributing 🙌🏽
No, I am afraid I cannot help regarding this
The text was updated successfully, but these errors were encountered: