balazsorban44
commented
3 years ago @cathykc As the original author of #895, I would like to ask you, how strongly do you feel about additionalAuthorizeParams being a provider property, instead of using the (new) third argument of the signIn client function?
Example:
<button
onClick={() =>Â signIn("slack", {}, {user_scope: 'identity.basic,identity.email,identity.avatar'})}
>
Login
</button>Right now, there are 2 ways of doing it, and we could eventually keep both, I was just curious about your opinion.
Setting authorize params may actually be useful for several providers and can be a general thing in contrast to the other, above mentioned magical provider properties, so I may even be OK with removing the authParams from the client signIn function instead. I might want to rename it to just authParams or authorizeParams removing the additional prefix.
UPDATE:
After giving it some thought, I think it makes more sense to keep your change and remove it from the signIn client-side function.
github-actions[bot]
Currently, there are some "magical" 🧙 fields only utilized by specific providers. We could handle these edge cases internally instead. All providers have an
id, which we can use to switch on different behaviors. It would also make it easier to keep a TypeScript provider interface simple, without the need for Discriminated Union or similarSome of these fields and which provider(s) use them (introduced in which PR):