Destructuring profile to allow override default fields

[vtcaregorodtcev]

Feature: This change will allow adjusting provider options to get more information about accounts.

What and Why:

For example: By default, Facebook provider configured only to accept clientId and clientSecret, but if we want to fetch, link to the profile we need to adjust those options with the following scope: 'email user_link', and profileUrl: 'https://graph.facebook.com/me?fields=email,name,picture,link',. And then after the user is going to log in, we miss additional info from options because of hardcoded part at https://github.com/nextauthjs/next-auth/blob/canary/src/server/lib/oauth/callback.js#L172

I suggest a destructuring of profile object to override the default fields.

Checklist:

This change will not introduce new behaviour or functionality except for extended possibilities.

• Documentation
• Tests
• Ready to be merged

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/nextauthjs/next-auth/4ht3b45zc
✅ Preview: https://next-auth-git-patch-1.nextauthjs.vercel.app

[balazsorban44]

Good point, I think I came to the same conclusion in #959, I didn't really understand why we don't propagate everything, but @iaincollins may have a reasoning here.

Although in the same file, on line 185 you can see we return the whole profile as well. Did you check if the info you need is available there in the jwt callback?

[vtcaregorodtcev]

Good point, I think I came to the same conclusion in #959, I didn't really understand why we don't propagate everything, but @iaincollins may have a reasoning here.

Although in the same file, on line 185 you can see we return the whole profile as well. Did you check if the info you need is available there in the jwt callback?

Yup, I've checked signIn callback and data come as 3rd argument, but this looks not naturally. In this case, we need additional action to assign data to a user in a place where we only check the access of the user.

Anyway, looks like my PR will not solve this problem, bc I see there are several places where this behaviour with predefined fields is hardcoded, sorry.