Docs: Add guidance for custom User type in Auth guides #7354
Conversation
Includes using the provider token to get profile information for the user as an example.
| @@ -94,14 +94,14 @@ base64url encode the resulting string. This new string is called the | |||
| * @returns {Object} The verifier and challenge strings | |||
| */ | |||
| const generatePKCE = () => { | |||
| const verifier = crypto.randomBytes(32).toString("base64url"); | |||
There was a problem hiding this comment.
Sorry about all the whitespace changes, I noticed the indentation was totally whack when updating stuff.
raddevon
changed the title
| const { auth_token } = await codeExchangeResponse.json(); | ||
| + | ||
| + const isSignUp = requestUrl.searchParams.get("isSignUp"); | ||
| + if (isSignUp === "true") { |
There was a problem hiding this comment.
Should we call out in some way that this depends on having this search parameter set up in handleAuthorize, maybe in a note or even in a comment in the code? My concern is that someone followed this example previously and doesn't have that new code to set the param which is added in this PR, sees only this addition, tries to implement, and fails because isSignup hasn't been set.
There was a problem hiding this comment.
That's a good callout, but it might be a little noisy for those who are following along from the beginning. I guess this is a drawback to not having this as like a fully fleshed out example in git to help track changes. Maybe in the proceeding paragraph we can remind the reader that we set up a separate redirect_to_on_signup value in the handleAuthorize handler?
There was a problem hiding this comment.
what say you?
Co-authored-by: Devon Campbell <devon@edgedb.com>
For email-based identities, show setting the
emailbased on the linkedEmailFactor. For OAuth, show using the provider token to get profileinformation for the user.