-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
[auth][error] CredentialsSignin, when return null for CredentialsProvider in the authorize function. #9900
Comments
Returning |
Here is the code solution: Try adding a new case to your switch statement: if (error instanceof AuthError) {
switch (error.type) {
case "CredentialsSignin":
return { msg: "Invalid credentials" , status: "error"};
case "CredentialsSignin":
throw error;
default:
return { msg: "Something went wrong", status: "error" };
}
} This works for me! |
great, error resolve @Jay-Karia |
@Jay-Karia's fix does not seem to work for me, "[auth][error] CredentialsSignin" logs are still printed to the console even with the additional switch case. Is there really no method to handle invalid credentials in authenticate without throwing an error?
|
100% |
Did you win it? |
I have win it. But it looks like a crutch. Before use signIn('credentials',{...}) execute checkup on isExisting smt if result will be null we return {error: 'error'} and if we found for example user we got pure data to method signIn. |
Why it this closed ? |
I do not know about you guys, but I could not find a good way to handle errors in v5, so I switched to v4 instead |
I agree with all of you about the error logs, but it solves the errors at frontend in the development server. |
This needs to be reopened |
so far, this is the only solution I can do with V5; simply check if the user actually exists or is valid before calling the authorization. It's not the best approach, unlike v4, but there's nothing we can do. |
@balazsorban44 so every time a login fails it will spawn an error on server side? It doesn't sound right to me. We should be able to handle failed login cases without treating it as an error, since it is not an error at all. |
I get it, it's frustrating as well, I am trying to find a good error handling method also but nothing seems to work. We need to understand tho that v5 is still in beta and it's not meant for production. |
Okay, I've just found a very stupid workaround (which is definitely not optimal, but solves this for now). Supposing that const onSubmit = async (formData: LoginUserPayload) => {
try {
// The function that calls your credentials API
await loginUser(formData);
/**
* If the previously call to `loginUser` is not successful (i.e login not successful),
* the control flow is passed to the catch block, therefore we only call the authenticate
* action if the response is 200, preventing the next-auth error to happen.
* https://github.com/nextauthjs/next-auth/issues/9900
*/
await authenticate(formData)
} catch (e) {
// handle the error (which should be an Axios error or similar) here.
setAuthError("Incorrect email or password")
}
}; Basically, you only call the next-auth methods if you are sure that the login is going to be successful (what is, you don't handle the failed login using next auth). This results in two repeated requests (in the successful case), but I could not find any other solution at the moment. |
I tried the solution they suggest, create a custom error class that extends from CredentialsSignIn and set a code. however, if condition to redirect is false, I am just getting a "Configuration" type error and code is empty. This has not been solved or I am not doing something right. |
// login.ts
I never get to hit the case 'CredentialsSignin' return with wrong email, password, etc... it always return me just the default! |
This mechanism actually works in import { AuthError } from 'next-auth';
class InvalidCredentials extends AuthError {
public readonly kind = 'signIn';
constructor() {
super('Invalid credentials');
this.type = 'CredentialsSignin';
}
} Especially the |
Bro, this is horrible, why not just not show an error when null is returned? |
I tried this but it wont return error to the client side |
I have some additional conditions that I want to send to the user, other than the invalid credentials. |
i have the same problem, but this import { AuthError } from 'next-auth';
class InvalidCredentials extends AuthError {
public readonly kind = 'signIn';
constructor() {
super('Invalid credentials');
this.type = 'CredentialsSignin';
}
} fix it |
I think I found a "work around" for this that is much easier to work with than suggested work around.
|
is it teribble? 😂 |
Lucia auth 😘 |
errors as values 😭 |
I guess calling the sign-in method only after we are sure that the credentials are valid is the way to go for now. I believe implementing this would be one possible solution |
I am starting to wonder if it is really a big deal if it does throws an error that panics...seems like it is already handled with a console log |
I'm also wondering the same thing |
I think It was just a bit confusing when following the docs, especially when someone is newish to nextauth and v5, it does not produce the expected result |
I definitely think it is a weird behaviour but the docs clearly state this is the expected behaviour |
Environment
System:
OS: Windows 11 10.0.22631
CPU: (24) x64 AMD Ryzen 9 3900X 12-Core Processor
Memory: 25.36 GB / 47.93 GB
Binaries:
Node: 20.11.0 - C:\Program Files\nodejs\node.EXE
npm: 10.2.4 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: Chromium (121.0.2277.98)
Internet Explorer: 11.0.22621.1
npmPackages:
@auth/prisma-adapter: ^1.2.1 => 1.2.1
next: 14.1.0 => 14.1.0
next-auth: ^5.0.0-beta.5 => 5.0.0-beta.5
react: ^18 => 18.2.0
Reproduction URL
https://github.com/AmphibianDev/todo-app/tree/main
Describe the issue
The error occurs only when
authorize
returns null, if it's returning a user, it works.How to reproduce
auth.config.ts
auth.ts
Error:
Expected behavior
Rejecting the singin attempt without throwing a server error in the console, and showing the user "Invalid credentials"
The text was updated successfully, but these errors were encountered: