-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added signinInfo
when signing in
#7234
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
@AlexErrant is attempting to deploy a commit to the authjs Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not confident about the flow of signinInfo
from query param => cookie; open to suggestions!
@@ -216,7 +216,7 @@ export interface VerificationToken { | |||
* ::: | |||
*/ | |||
export interface Adapter { | |||
createUser?(user: Omit<AdapterUser, "id">): Awaitable<AdapterUser> | |||
createUser?(user: Omit<AdapterUser, "id">, info?: { signinInfo?: SigninInfo }): Awaitable<AdapterUser> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I add it as an optional param so it may be extended in the future with other data. Also shouldn't break exiting adapters.
if (request.body?.signinInfo !== undefined) { | ||
const expires = new Date() | ||
expires.setTime(expires.getTime() + SIGNIN_INFO_MAX_AGE * 1000) | ||
cookies.push({ | ||
name: options.cookies.signinInfo.name, | ||
value: request.body.signinInfo, | ||
options: { | ||
...options.cookies.signinInfo.options, | ||
expires, | ||
}, | ||
}) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely no idea if this is the right place to put it... but it works!
nonce: CookieOption | ||
} | ||
|
||
export type SigninInfo = string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it SigninInfo
or SignInInfo
🤔🤔 Choosing the former arbitrarily because less stuttering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @AlexErrant thanks for sending the PR! After discussed with @balazsorban44 we agreed that we don't want to have this built in at the moment - We will revisit this PR once we see enough interests for it 🫶 Thanks again for your understanding
I suppose the workaround would be intercepting the request using Advanced Initialization and handle the extra query params in the application code.
@ThangHuuVu I don't tag you lightly, but may I encourage you to reconsider this? The issue this fixes has +9, which would put it in the top three most "reactions" issues... if it weren't closed by StaleBot. If this doesn't qualify as enough interest, I would inquire as to what would qualify as enough interest. Note too that the people who upvote that issue are probably people who aren't using the NextAuth because it doesn't meet their business requirements; it would naturally have low engagement because people don't often look for a new auth library. As to your workaround of intercepting the request, that's impossible because in the Authorization Code flow, the code must be only used once.
Here's the series of interceptable requests as seen by the constructor when I try what's in Advanced Initialization:
That final GET is the final redirect to the homepage, and the penultimate GET is the code request which application code cannot use without violating the OAuth spec. Devs cannot use the code to get the profile to add the user to the database. I don't mean to be argumentative. Please let me know if I'm missing something in my attempted workaround. I understand that you're trying to reduce the maintenance burden, but far as I can tell this feature is impossible to implement in application code, at least via what's suggested in Advanced Initialization. |
hello, @AlexErrant thanks for the detailed comment, I apologize for giving you the incorrect workaround. If I understand correctly, this feature is only helpful for the Email login flow. For the OAuth flow, you can add signIn('github', undefined, { foo: 'bar'}) and you will receive it in the 4th request
Right now we are focusing on shipping v5 and will re-visit the PR once we reach a more stable after the release. I apologize again for the inconvenience. 🫶 |
☕️ Reasoning
Since this PR seems abandoned, I took the initiative of moving it to
packages/core
as suggested by Thang.I made some changes to the naming and semantics. Instead of being specific to new users, the name
signinInfo
refers to info passed in during the signin process. After all, without an adapter, isn't every user "new"?🧢 Checklist
🎫 Affected issues
Supersedes #4747
Fixes #1069