4.18.4 no longer respects signIn(..., {redirect: false})

[EvHaus]

Environment

System:
OS: Linux 5.15 Ubuntu 22.04.1 LTS 22.04.1 LTS (Jammy Jellyfish)
CPU: (24) x64 AMD Ryzen 9 3900X 12-Core Processor
Memory: 24.48 GB / 31.32 GB
Container: Yes
Shell: 5.1.16 - /bin/bash
Binaries:
Node: 17.8.0 - ~/.nvm/versions/node/v17.8.0/bin/node
Yarn: 1.22.19 - ~/.yarn/bin/yarn
npm: 8.5.5 - ~/.nvm/versions/node/v17.8.0/bin/npm
npmPackages:
next: 13.0.6 => 13.0.6
next-auth: 4.18.0 => 4.18.0
react: 18.2.0 => 18.2.0

Reproduction URL

https://stackblitz.com/edit/github-61ga3k-pvybxx?file=pages%2Findex.tsx,pages%2Fapi%2Fauth%2F[...nextauth].ts

Describe the issue

After upgrading from 4.18.0 to 4.18.4 I noticed that signIn(..., {redirect: false}) is no longer respecting the redirect: false option.

In my app I have a CredentialsProvider and I issue a signIn request like this:

const result = await signIn('myapp-login', {
    {username, password},
    redirect: false,
});

In 4.18.0, after a successful login, it this would return:

{
    error: null,
    ok: true,
    status: 200,
    url: "http://localhost:3000/login"
}

But in 4.18.4 it returns:

{
    error: null,
    ok: false,
    status: 302,
    url: "http://localhost:3000/login"
}

How to reproduce

Create an example app with [email protected] and update the signIn() call in the header to use the redirect: false option. Proceed to login and check the response of the signIn() request.

Expected behavior

The signIn() call should resolve with an ok: true object upon successful login.

[balazsorban44]

Identified the issue, here is an experimental release to test out: #6004 (comment)

[violabg]

I have the same issue, it started with the release of v 4.18.1.
I have tested with pnpm add [email protected], and I confirm that is working.
Thanks

[balazsorban44]

This should be fixed in 4.18.5, please give it a try!

[balazsorban44]

Please open a new issue with a minimal reproduction.

[TerrySlack]

I'm still getting this in 4.18.7. Reverted to 4.18.0 and the issue is still there.
However, when using 4.18.5, the error is not there.

[nmicun]

I have the same problem with @auth/core 0.2.5 in SvelteKit, redirect: false is not working, response is undefined.
Solved by removing !error from if statement:

 if (redirect || !isSupportingReturn || **!error**) 
{
    // TODO: Do not redirect for Credentials and Email providers by default in next major
    window.location.href = data.url ?? callbackUrl
    // If url contains a hash, the browser does not reload the page. We reload manually
    if (data.url.includes("#")) window.location.reload()
    return

  }

[binaryme]

@nmicun I discovered the same behavior in sveltekit, but instead of removing error I opted for converting error to a boolean:
if (redirect || !isSupportingReturn || Boolean(error)) { // TODO: Do not redirect for Credentials and Email providers by default in next major window.location.href = data.url ?? callbackUrl; // If url contains a hash, the browser does not reload the page. We reload manually if (data.url.includes("#")) window.location.reload(); return; }

I console logged the evaluated variables and discovered that if there is no error, error returns null
🚀 ~ file: client.js:10 ~ signIn ~ redirect: false client.js:15 🚀 ~ file: client.js:15 ~ signIn ~ isSupportingReturn: true client.js:38 🚀 ~ file: client.js:37 ~ signIn ~ error: null

that's why removing error in your case temporarily fixed the issue.

[WolfVector]

I'm also using sveltekit, In my case I fixed it by doing

if ((redirect || !isSupportingReturn) && !error) {
  // TODO: Do not redirect for Credentials and Email providers by default in next major
  window.location.href = data.url ?? callbackUrl;
  // If url contains a hash, the browser does not reload the page. We reload manually
  if (data.url.includes("#")) window.location.reload();
  return;
}

res.error = error
return res

Just like @binaryme said, error is null when the signIn is successfull and it is a string when there is an error. So in this way, the returned object will have the error property and you could check what value it has.