next-auth: support throwing custom errors from `signIn` callback

Description 📓

Sign-in callback promise (at least for Svelekit provider) resolves to boolean, which is too blunt for providing feedback to the end-user in error case (i.e., returns false). Please change return type to number or boolean | number so client can provide more actionable response to end-user in event of sign-in failure (e.g., duplicate account, account suspended, no such email, etc.)

Thank you!

    signIn: (params: {
        user: User | AdapterUser;
        account: A | null;
        profile?: P;
        email?: {
            verificationRequest?: boolean;
        };
        credentials?: Record<string, CredentialInput>;
    }) => Awaitable<boolean>;

How to reproduce ☕️

N/A

Contributing 🙌🏽

Yes, I am willing to help implement this feature in a PR

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 17 (4 by maintainers)

Most upvoted comments

It doesn’t seem like there is any support for custom errors still (on @auth/core or sveltekit). I might be doing something wrong, but throwing errors doesn’t work, returning strings doesn’t work (#8422), and the docs do not mention anything that might allow this.

I’d like to re-open this issue, but it doesn’t seem I’m able to.

Add this to the migration guide:

Before (next-auth v4):

        return `/login?error=${err}&param2=${isBoolean ? 1 : 0}`

After (next-auth v5):

class CustomAuthError extends AuthError {
            static type = `${err as string}&param2=${isBoolean ? 1 : 0}`
          }

          throw new CustomAuthError(e)
// would be almost the same `/login?error...`

NOTE: The difference is that the string from static type will be URL parsed for safety reasons. You need to parse the params yourself and create a workaround, I also use search params parsing workaround to migrate to the new v5 beta.

Something like this, you can hack as you like. but remember that it’s not a best practice to pass information from server to client if you’re not sure.

@JoaoPedroCamargo No, unfortunately not.