Add webhook provider (Proof of Concept) #409
Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/iaincollins/next-auth-docs/8abmtzic8 |
| name: "Webhook", | ||
| maxAge: 24 * 60 * 60, // How long link are valid for (default 24h) | ||
| ...options, | ||
| sendVerificationRequest: ({ |
There was a problem hiding this comment.
The name is "inherited" from the email provider, nothing says it couldn't change.
You would do whatever you want here, like, sending the email, sending an sms, hitting a webhook
| } | ||
| } else if (providerAccount.type === "webhook") { | ||
| // If signing in with an email, check if an account with the same email address exists already | ||
| const userByEmail = profile.phoneNumber |
There was a problem hiding this comment.
phoneNumber is hardcoded here, need to find out a way to pass in the attribute to this method, and obviously names are off because of copying/pasting email behavior
| } else if (providerAccount.type === "webhook") { | ||
| // If signing in with an email, check if an account with the same email address exists already | ||
| const userByEmail = profile.phoneNumber | ||
| ? await getUserByAttribute("phoneNumber", profile.phoneNumber) |
There was a problem hiding this comment.
This is the main change from the email, getUserByAttribute let's you specify an attribute name and a value instead of assuming email
| } | ||
| } | ||
|
|
||
| // // Update emailVerified property on the user object |
There was a problem hiding this comment.
Need to figure out how to deal with this, maybe have a verificationProperty on the provider so we know which field to set to true when verification.
| @@ -0,0 +1,37 @@ | |||
| import { randomBytes } from "crypto"; | |||
There was a problem hiding this comment.
Exact same as src/server/lib/signin/email.js but recieves an extra value ((attribute, value, provider, options) instead of (email, provider, options))
|
|
||
| // @TODO Create invite (send secret so can be hashed) | ||
| await createVerificationRequest( | ||
| attribute + ":" + value, |
There was a problem hiding this comment.
We change the identifier here to attribute:value to keep track of what we're validating in the db
| ); | ||
| res.end(); | ||
| return done(); | ||
| } else if (provider.type === "webhook") { |
There was a problem hiding this comment.
This would read from the body to get the correct info and pass it on, implementation is missing mainly because of this being a PoC, not sure how similar its gonna be to email.
|
Left tons of comments on the relevant parts, excuse the prettier mess! |
| } | ||
| } | ||
|
|
||
| async function getUserByEmail (email) { | ||
| debugMessage('GET_USER_BY_EMAIL', email) | ||
| async function getUserByAttribute(attribute, value) { |
There was a problem hiding this comment.
Basically the same as getUserByEmail but with 2 params
|
Thank you for all the comments on this! <3 |
|
Still working on the backlog, but will circle back to this! |
|
Hi there! It looks like this issue hasn't had any activity for a while. It will be closed if no further activity occurs. If you think your issue is still relevant, feel free to comment on it to keep ot open. Thanks! |
|
Hi @tmayr, would you be interested in getting this up-to-date? |
|
@balazsorban44 Sure, any insights on what has changed (anything worthy mentioning)/or if theres any extra modifications the team would like me to apply/explore conceptually? |
|
Hi there! So after a recent chat with another maintainer of this repo, we discussed how we could expand on the |
This is 101% a proof of concept that needs to be cleaned up, it has my prettier configuration applied so even the review is a bit messy, just focus on the big code blocks which were added more than anything.
There's a lot of repetition as I mentioned, because the
email provideris 90% similar, so taking on the same flow, I mostly copied/pasted and made it a bit more generic with takingattributeandvalueinstead of hardcoding email and assuming it.It also changes how the
identifieris used, before it was just theemailvalue, now itsattribute:valueFor now,
phoneNumberis hardcoded in some parts, but thinking this would come from theproviderconfiguration (say you specify{ validationAttribute }or something like that, so you could specify whatever you want.Will leave some comments on the blocks that are actually behavior change
@iaincollins Take a look whenever you can!, will wait for v3 before polishing this based on whatever comes up.
Refs #406