Provider type
Email
Environment
System:
OS: macOS 12.2.1
CPU: (10) arm64 Apple M1 Max
Memory: 6.94 GB / 64.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 16.16.0 - ~/.nodenv/versions/16.16.0/bin/node
Yarn: 1.22.19 - ~/.yarn/bin/yarn
npm: 8.11.0 - ~/.nodenv/versions/16.16.0/bin/npm
Browsers:
Chrome: 103.0.5060.114
Safari: 15.3
npmPackages:
next: ^12.1.6 => 12.1.6
next-auth: =4.2.1 => 4.2.1
react: 17.0.2 => 17.0.2
Reproduction URL
https://github.com/skillrecordings/products/blob/main/apps/testingaccessibility/src/pages/api/auth/%5B...nextauth%5D.ts
Describe the issue
Many organizations utilize various email scanning mechanism that will actively follow links in email messages. When this occurs with a next-auth email provider email, it results in the VerificationToken being used and thus instantly invalidated for the human user that clicks the link seconds, minutes, or hours later.
The link is never valid for the human user no matter how many times they try.
Microsoft 365 Advanced Threat Protection
Bing Preview Clicks Links
This has been previously discussed: #4585
some additional information on stack exchange: https://security.stackexchange.com/a/211293
The "?redirect=true" approach seems very reasonable to me, so if the follow param is missing, render this:
<!DOCTYPE html>
<html>
<body>
<script>
var queryParams = new URLSearchParams(window.location.search);
queryParams.set("follow", "true");
history.replaceState(null, null, "?"+queryParams.toString());
</script>
</body>
</html>alternatively if we could allow them to be valid for a period of time with unlimited use that would suit our needs specifically, and might help others with tradeoffs.
If this isn't an issue and should remain in the above discussion, please feel free to close it.
How to reproduce
This is tricky. I've got a user that this occurs to consistently, but you need to setup a Baracuda or various Microsoft tools that robo-click emails.
Expected behavior
Human users should get verification links that work.
|
} else if (provider.type === "email") { |
Provider type
Email
Environment
System:
OS: macOS 12.2.1
CPU: (10) arm64 Apple M1 Max
Memory: 6.94 GB / 64.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 16.16.0 - ~/.nodenv/versions/16.16.0/bin/node
Yarn: 1.22.19 - ~/.yarn/bin/yarn
npm: 8.11.0 - ~/.nodenv/versions/16.16.0/bin/npm
Browsers:
Chrome: 103.0.5060.114
Safari: 15.3
npmPackages:
next: ^12.1.6 => 12.1.6
next-auth: =4.2.1 => 4.2.1
react: 17.0.2 => 17.0.2
Reproduction URL
https://github.com/skillrecordings/products/blob/main/apps/testingaccessibility/src/pages/api/auth/%5B...nextauth%5D.ts
Describe the issue
Many organizations utilize various email scanning mechanism that will actively follow links in email messages. When this occurs with a next-auth email provider email, it results in the VerificationToken being used and thus instantly invalidated for the human user that clicks the link seconds, minutes, or hours later.
The link is never valid for the human user no matter how many times they try.
Microsoft 365 Advanced Threat Protection
Bing Preview Clicks Links
This has been previously discussed: #4585
some additional information on stack exchange: https://security.stackexchange.com/a/211293
The "?redirect=true" approach seems very reasonable to me, so if the
followparam is missing, render this:alternatively if we could allow them to be valid for a period of time with unlimited use that would suit our needs specifically, and might help others with tradeoffs.
If this isn't an issue and should remain in the above discussion, please feel free to close it.
How to reproduce
This is tricky. I've got a user that this occurs to consistently, but you need to setup a Baracuda or various Microsoft tools that robo-click emails.
Expected behavior
Human users should get verification links that work.
next-auth/packages/next-auth/src/core/routes/callback.ts
Line 199 in 2725d07