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 various auth flows provide data in pieces unnecessarily. Certain applications/adapters may benefit from receiving that data simultaneously. Particularly getUserByAccount -> createUser -> linkAccount never gives you AdapterUser and AdapterAccount simultaneously.
Non-Goals
I do not intend to prevent people from continuing to build adapters the current way with createUser and linkAccount logic fully staged and separated, nor am I even suggesting that it shouldn't be the default, I just don't want that to be required.
Background
The decision to encourage a one-to-zero-or-more relation between user and account for most apps is reasonable, however in a variety of situations a one-to-one or one-to-one-or-more relation is nicer, for example a tight integration with a single IdP or just a simple app that doesn't want to deal with multiple accounts. Currently it's rather painful to enforce such a model without hacky workarounds like allowing NULL on fields that should really never actually be NULL.
Proposal
One option would be a createUserWithAccount method that provides both, and defaults to just calling createUser and then linkAccount in sequence, but would allow you to hook into it. Another would just be providing additional arguments to existing functions providing the totality of what auth.js knows at that time, leaving the first argument alone for full backwards compatibility.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Goals
Currently various auth flows provide data in pieces unnecessarily. Certain applications/adapters may benefit from receiving that data simultaneously. Particularly
getUserByAccount
->createUser
->linkAccount
never gives you AdapterUser and AdapterAccount simultaneously.Non-Goals
I do not intend to prevent people from continuing to build adapters the current way with createUser and linkAccount logic fully staged and separated, nor am I even suggesting that it shouldn't be the default, I just don't want that to be required.
Background
The decision to encourage a one-to-zero-or-more relation between user and account for most apps is reasonable, however in a variety of situations a one-to-one or one-to-one-or-more relation is nicer, for example a tight integration with a single IdP or just a simple app that doesn't want to deal with multiple accounts. Currently it's rather painful to enforce such a model without hacky workarounds like allowing NULL on fields that should really never actually be NULL.
Proposal
One option would be a
createUserWithAccount
method that provides both, and defaults to just callingcreateUser
and thenlinkAccount
in sequence, but would allow you to hook into it. Another would just be providing additional arguments to existing functions providing the totality of what auth.js knows at that time, leaving the first argument alone for full backwards compatibility.Beta Was this translation helpful? Give feedback.
All reactions