Replies: 3 comments 1 reply
-
I'm actually having the same issue right now, and I can't believe @cyrus-za is the only one before me. Seems counter-intuitive to have to trigger a second request in order to augment the user record. Is there any other best practice that I'm missing here when it comes to augmenting user's default fields? |
Beta Was this translation helpful? Give feedback.
-
Thanks for raising this! If using Auth0 as the sole provider, you can use leverage a custom (We are thinking of introducing an additional high level callback to do something similar which would apply to make it easy to normalise user profiles across all configured providers in a single place.) RE: Use of Display NameThis is something we encourage by design and represents what many service designers have come to regard as best practice. It is a similar problem to the one with storing street addresses; just as the format for addresses is not universal (but there are abstracts that work well) the convention for names is not universal across all nationalities or cultures or contexts. That people often anticipate this (often for bureaucratic reasons) further complicates things, How names are represented across by different providers reflects this too, which is also the reason why it's the only way to realistically possible model names as accurately as possible is to use a single free form value that allows people to choose how they wish to be addressed. A particular problem is trying to map ConstraintsSome services maybe forced to store data following assumed conventions for third party integration; such as for local address lookup or credit service integration with APIs that have built-in assumptions about naming conventions. Often services that need to do this have specific stores for that data (e.g. "Billing details", "Shipping details") to reflect people's formal identity in those context may be different for legal / bureaucratic reasons so that data can be use appropriately in each context. e.g. Details may need to match formal legal names on bank details, invoice or shipping label is one example, because people might have to use ID that exactly matches a specific form of ID they have, and which differs from the name they usually use and want to be addressed by in other contexts. |
Beta Was this translation helpful? Give feedback.
-
It's possible to override any method of the adapter by simple object destructuring: adapters: [{
...PrismaAdapter(prisma),
createUser() { ... }
updateUser() { ... }
}] |
Beta Was this translation helpful? Give feedback.
-
I am using the Prisma Adapter and it's great, but I had to fork my own one and customize it, because the createUser and updateUser methods hardcode which props from the profile gets saved.
Despite the docs allowing us to extend the prisma schema and add more columns, it does not help if we cannot extend the adapter itself. I got a very common use-case: split name into firstName and lastName. In order to get that, I had to
Ideally we should be able to extend the provider's profile and the whole object gets spread to the prisma calls for createUser and updateUser, but I am not sure if prisma will just ignore fields that are not on the schema or throw an error. If it throws an error, the adapter would need to check on the prisma schema which fields are there (luckily prisma generates these so should not need to do string/AST actions on the schema itself) and filter out the ones not on the schema.
More ideal: next-auth should simply default to firstName and lastName. It is a lot easier for the api consumer (react components) to join 2 props together in a string than to split them up (some people have middle names and some surnames are multi-word), but even if we switch the default to first and last name, the above is still valid any other fields to extend on the prisma schema. Ideally one should be able to add a bunch of data from the auth0 profile to the user table such as locale, roles, phone number, etc.
None of this should require a hacky signin callback to make a secondary prisma db call on each login. It should simply be an option passed to the prisma adaptor to overwrite the fields saved (given provider profile) and it should be type-safe based on the types generated by prisma client to show which fields can be passed to the adapter to store.
We could even go as far as to allow someone to overwrite the entire createUser and updateUser function, without the need to copy paste the entire adapter (and thus maintain it). If the adaptor can have callbacks/hooks just like next-auth itself has, we can choose what we overwrite and what we stick to. This will also allow people to quickly get unblocked if there's some breaking changes intrduced by the prisma team like we saw in 2.12 and 2.14.
Beta Was this translation helpful? Give feedback.
All reactions