NextAuth not working behind corporate proxy

[raphaelpc]

Description 🐜

NextAuth is not working behind corporate proxy.

I studied the current NextAuth implementation and found that this error happens because NextAuth makes use of the "node-auth" library (npm package "oauth") in it's "oAuthClient" (src/server/lib/oauth/client.js), which requires manually setting up an agent to be used by the "https" library.

I created a PR with the solution of the problem:
#2493

Related discussion: #676
Related StackOverflow: https://stackoverflow.com/questions/32130471/node-js-https-not-working-behind-corporate-proxy

If the PR is not going to be accepted, i believe it is important do register the issue here for other people facing the same problems that i'm facing right now (which are quite time consuming to debug).

Is this a bug in your own project?

No

How to reproduce ☕️

Just run any application with NextAuth behind a corporate proxy and try to log in with a Provider (like Google or GitHub).

Screenshots / Logs 📽

[next-auth][error][oauth_get_access_token_error] 
https://next-auth.js.org/errors#oauth_get_access_token_error Error: connect ETIMEDOUT 216.58.202.141:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16) {
  errno: -4039,
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '216.58.202.141',
  port: 443
} undefined undefined
[next-auth][error][oauth_get_access_token_error]
https://next-auth.js.org/errors#oauth_get_access_token_error Error: connect ETIMEDOUT 216.58.202.141:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16) {
  errno: -4039,
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '216.58.202.141',
  port: 443
} google 4/0AX4XfWiDMdHUjXWR1xqLs8bGa1g5CEJOdBiypyNPA3b4vzJHeqxOGFownSkn5ABA885Asw
[next-auth][error][oauth_callback_error]
https://next-auth.js.org/errors#oauth_callback_error Error: connect ETIMEDOUT 216.58.202.141:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16) {
  errno: -4039,
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '216.58.202.141',
  port: 443
}

Environment 🖥

System:
OS: Windows 10 10.0.19042
CPU: (12) x64 Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
Memory: 6.80 GB / 15.78 GB
Binaries:
Node: 14.16.1 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 6.14.12 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: 44.19041.423.0
Internet Explorer: 11.0.19041.1
npmPackages:
react: ^17.0.2 => 17.0.2

Contributing 🙌🏽

Yes, I am willing to help solve this bug in a PR

[raphaelpc]

To resolve this issue locally, i'm now using patch-package.

I'm applying this patch:

diff --git a/node_modules/next-auth/dist/server/lib/oauth/client.js b/node_modules/next-auth/dist/server/lib/oauth/client.js
index e35acd0..5b666ec 100644
--- a/node_modules/next-auth/dist/server/lib/oauth/client.js
+++ b/node_modules/next-auth/dist/server/lib/oauth/client.js
@@ -9,6 +9,10 @@ exports.default = oAuthClient;
 
 var _oauth = require("oauth");
 
+var UrlLib = require("url");
+
+var HttpsProxyAgent = require("https-proxy-agent");
+
 var _querystring = _interopRequireDefault(require("querystring"));
 
 var _logger = _interopRequireDefault(require("../../../lib/logger"));
@@ -150,6 +154,12 @@ async function getOAuth2AccessToken(code, provider, codeVerifier) {
   const postData = _querystring.default.stringify(params);
 
   return new Promise((resolve, reject) => {
+    let parsedUrl = UrlLib.parse(url, true);
+    if (parsedUrl.protocol == "https:" && process.env.http_proxy) {
+      let agent = new HttpsProxyAgent(process.env.http_proxy);
+      this.setAgent(agent);
+    }
+
     this._request('POST', url, headers, postData, null, (error, data, response) => {
       if (error) {
         _logger.default.error('OAUTH_GET_ACCESS_TOKEN_ERROR', error, data, response);
@@ -228,6 +238,12 @@ async function getOAuth2(provider, accessToken, results) {
   }
 
   return new Promise((resolve, reject) => {
+    let parsedUrl = UrlLib.parse(url, true);
+    if (parsedUrl.protocol == "https:" && process.env.http_proxy) {
+      let agent = new HttpsProxyAgent(process.env.http_proxy);
+      this.setAgent(agent);
+    }
+
     this._request(httpMethod, url, headers, null, accessToken, (error, profileData) => {
       if (error) {
         return reject(error);

It would be great if this issue could be resolved in future versions!

Thanks in advance.

[ndom91]

@raphaelpc we released a beta for the new NextAuth v4 version today which uses the newer openid-client instead of node-oauth. Unfortunately there is still no built-in support for proxying.

They use sindresorhus/got for http requests, and you can set a custom agent so it shouldn't be too difficult to write up a workaround like the one you detailed here in your patch-package diff.

Notes:

• openid-client issue: Question: How do I set up proxy settings? panva/openid-client#22
• openid-client docs 'customizing http requests': https://github.com/panva/node-openid-client/tree/main/docs#customizing-http-requests
• got docs on proxies: https://github.com/sindresorhus/got/tree/v11.8.0#proxies

Thinking out loud here based off the info in the above links.. but maybe here (https://github.com/nextauthjs/next-auth/blob/beta/src/server/lib/oauth/client.js), adding something along these lines?

const { custom } = require('openid-client');
const { HttpsProxyAgent } = require('hpagent');

custom.setHttpOptionsDefaults({
  agent: {
    https: new HttpsProxyAgent({
	keepAlive: true,
	keepAliveMsecs: 1000,
	maxSockets: 256,
	maxFreeSockets: 256,
	scheduling: 'lifo',
	proxy: 'https://localhost:8080'
    })
  }
});

[ThePaulMcBride]

I've had this same issue I think. I have a site (wecodeni.com) that uses next-auth.js. Every now and then I'll have a customer get in touch saying they can't sign up when using the email login. I can never work out exactly what is causing it, but it's always from larger corporate customers.

I can see from my database that a user is created in these cases, but the user is presented with the ?error=Verification error. Is there anything I can do to stop this from happening?

I'm pretty sure what's happening is their email server is scanning links in emails, and by requesting the link in the signin email, they are claiming it, and so the user can't then signin.

[ndom91]

@ThePaulMcBride looks like this might be a result of the invites being expired.

See:

next-auth/packages/next-auth/src/core/routes/callback.ts

Lines 213 to 216 in a72f1b6

	const invalidInvite = !invite || invite.expires.valueOf() < Date.now()
	if (invalidInvite) {
	return { redirect: `${url}/error?error=Verification`, cookies }
	}

EDIT: Sorry just reread your email. We had an issue like this before with Office365, for example, like you suggested - it'll "check" the link to make sure its not a phishing site or whatever, thereby "using" up the invitation link. Let me see if I can find the issue / discussion again.

There was a way to disable it in office365 and some other discussion.

EDIT 2: Yeah here it is! #1840

[raphaelpc]

Behind corporate proxy Next Auth unfortunately won't work with our adjustments. I've been trying to update NextAuth to the latest release on my application, but I did not yet discover what patch should I create in order for it to work, like I did in the older version. Did anyone find a solution? Thanks. Em qua., 9 de fev. de 2022 às 18:21, Nico Domino ***@***.***> escreveu:

…

@ThePaulMcBride <https://github.com/ThePaulMcBride> looks like this might be a result of the invites being expires. See: https://github.com/nextauthjs/next-auth/blob/a72f1b6d21da89b4223542006c865862635c027b/packages/next-auth/src/core/routes/callback.ts#L213-L216 — Reply to this email directly, view it on GitHub <#2509 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHGXJF2PMLRIWSQTXHMCJHDU2LLD5ANCNFSM5B2N23GQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ndom91]

As mentioned in @balazsorban44's final reply in that issue, you could modify the [...nextauth].js config file (which is a "normal" catch-all API route at the end of the day), to just return a 200 immediately upon receiving a HEAD request.

This should satisfy most URL checking / SafeLink behavior, and not allow the email invitation tokens to be used up.

Something like:

import type { NextApiRequest, NextApiResponse } from "next"
import NextAuth from "next-auth"

export default async function auth(req: NextApiRequest, res: NextApiResponse) {

  if(req.method === "HEAD") {
     return res.status(200)
  }
  
  ...
}

See NextAuth.js - Advanced Initialization for more details, as well as the issue #1840 as previously mentioned.

[rnbrady]

I've been running this in production for a few month and unfortauntely it doesn't cover all cases, as some email security software sends a GET request. Latest one was this morning with User-Agent: Go-http-client/2.0

Edit: apologies, I may be in wrong thread. i'm talknig about the user being behind a firewall when logging in, not the NextAuth server being behind a firewall.

[raphaelpc]

Hello Nico! Thanks for the answer! But I did not understand how this could be applied to this situation, since the problem is that the methods used internally by NextAuth don't work behind a corporate proxy. That is why a had to create a patch-package for v3 in the first place. The thing is that I did not yet discover what patch I should apply on v4 since all the internal methods used for making requests changed from v3 to v4, like you mentioned in your first reply to this thread. I checked all references you posted but was not able to identify exactly what would need to be done for the methods to start checking on proxy environment info when making the requests to external services (for example, to the Google or Facebook auth endpoints). If that could be resolved only using advanced inicialialization that would be great, but I really did not identify how that could be used in this case. Em qua., 9 de fev. de 2022 às 18:29, Nico Domino ***@***.***> escreveu:

…

As mentioned in @balazsorban44 <https://github.com/balazsorban44>'s final reply in that issue, you could modify the [...nextauth].js config file (which is a "normal" catch-all API route at the end of the day), to just return a 200 immediately upon receiving a HEAD request. This should satisfy most URL checking / SafeLink behavior, and not allow the email invitation tokens to be used up. Something like: import type { NextApiRequest, NextApiResponse } from "next"import NextAuth from "next-auth" export default async function auth(req: NextApiRequest, res: NextApiResponse) { if(req.method === "HEAD") { return res.status(200) } ...} See NextAuth.js - Advanced Initialization <https://next-auth.js.org/configuration/initialization#advanced-initialization> for more details, as well as the issue #1840 <#1840> as previously mentioned. — Reply to this email directly, view it on GitHub <#2509 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHGXJF5J36AISKLNAHIE3I3U2LME5ANCNFSM5B2N23GQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[raphaelpc]

Important to clarify that Paul's error isn't necessarily the same as mine, but the situation that I described on this thread is related to corporate proxy, I don't even use the mail functionalities from NextAuth. Em qui., 10 de fev. de 2022 às 09:09, Raphael Cavalcanti ***@***.***> escreveu:

…

Hello Nico! Thanks for the answer! But I did not understand how this could be applied to this situation, since the problem is that the methods used internally by NextAuth don't work behind a corporate proxy. That is why a had to create a patch-package for v3 in the first place. The thing is that I did not yet discover what patch I should apply on v4 since all the internal methods used for making requests changed from v3 to v4, like you mentioned in your first reply to this thread. I checked all references you posted but was not able to identify exactly what would need to be done for the methods to start checking on proxy environment info when making the requests to external services (for example, to the Google or Facebook auth endpoints). If that could be resolved only using advanced inicialialization that would be great, but I really did not identify how that could be used in this case. Em qua., 9 de fev. de 2022 às 18:29, Nico Domino ***@***.***> escreveu: > As mentioned in @balazsorban44 <https://github.com/balazsorban44>'s > final reply in that issue, you could modify the [...nextauth].js config > file (which is a "normal" catch-all API route at the end of the day), to > just return a 200 immediately upon receiving a HEAD request. > > This should satisfy most URL checking / SafeLink behavior, and not allow > the email invitation tokens to be used up. > > Something like: > > import type { NextApiRequest, NextApiResponse } from "next"import NextAuth from "next-auth" > export default async function auth(req: NextApiRequest, res: NextApiResponse) { > > if(req.method === "HEAD") { > return res.status(200) > } > > ...} > > See NextAuth.js - Advanced Initialization > <https://next-auth.js.org/configuration/initialization#advanced-initialization> > for more details, as well as the issue #1840 > <#1840> as previously > mentioned. > > — > Reply to this email directly, view it on GitHub > <#2509 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AHGXJF5J36AISKLNAHIE3I3U2LME5ANCNFSM5B2N23GQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[ThePaulMcBride]

Sorry for jumping on your thread Rapheal, I initially had thought we were seeing the same thing!

[ndom91]

@raphaelpc ah right, okay my bad. The suggestion I made/wrote a tutorial for in the docs was strictly for the issue of corporate email clients / email services sending HEAD requests to the Email invitation links, in affect "using them up" so that they are no longer valid once the user tries to click on them. This seems to eb @ThePaulMcBride's problem, right?

In terms of corporate proxy in general, we're now using openid-connect which uses node's built-in http and https modules to make requests (Source). And it doesn't look like those two modules support the common HTTP_PROXY and HTTPS_PROXY environment variables. (See: http docs, https docs).

Therefore, you'll have to either fork and modify openid-client to use an http client that supports these proxy environment variables out of the box (like axios or got). Or use some sort of global proxy work-around like global-tunnel. I've used global-tunnel before to setup a MITM proxy for an app, its super simple to use. Check out this stackoverflow post on using it to add proxy support to http / https: https://stackoverflow.com/a/25122807/9579094

With global-tunnel implemented, you can either set a corporate proxy in the JS setup method of global tunnel, or use the common HTTP_PROXY / HTTPS_PROXY environment variables.

[balazsorban44]

HEAD requests should not be a problem, see my comment: #3900 (review)

Regarding fixing with a patch, openid-clinet allows you to set your agent for requests: https://github.com/panva/node-openid-client/blob/main/docs/README.md#customizing-individual-http-requests if that is any helpful. We create the client here:

next-auth/packages/next-auth/src/core/lib/oauth/client.ts

Line 34 in 68e412b

const client = new issuer.Client(

We let all openid-client settings pass through https://next-auth.js.org/configuration/providers/oauth#client-option but the agent setting is somewhat obscure (I think on purpose) and you can only modify it after the client has been created. So not sure if it would be possible without a change from us or patching.

[raphaelpc]

HEAD requests should not be a problem, see my comment: #3900 (review)

Regarding fixing with a patch, openid-clinet allows you to set your agent for requests: https://github.com/panva/node-openid-client/blob/main/docs/README.md#customizing-individual-http-requests if that is any helpful. We create the client here:

next-auth/packages/next-auth/src/core/lib/oauth/client.ts

Line 34 in 68e412b

const client = new issuer.Client(

We let all openid-client settings pass through https://next-auth.js.org/configuration/providers/oauth#client-option but the agent setting is somewhat obscure (I think on purpose) and you can only modify it after the client has been created. So not sure if it would be possible without a change from us or patching.

Thanks for the tip.

I have now been able to patch NextAuth v4 to be able to use it behind corporate proxy.

This is what i did:

1. First, i tried to resolve the problem directly through NextAuth configuration, exploring this option that is already provided:

next-auth/packages/next-auth/src/core/lib/oauth/client.ts

Line 16 in 68e412b

if (provider.httpOptions) custom.setHttpOptionsDefaults(provider.httpOptions)

To do so, i first updated my Provider at [...nextauth].ts:

    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
      httpOptions: {
        agent: new HttpsProxyAgent(process.env.http_proxy),
      },
    }),

Doing like that it unfortunately didn't work. I got this error:

message: 'The "options.agent" property must be one of Agent-like Object, undefined, or false. Received an instance of Object'

Probably because the way the "agent" is being received by the openidClient function makes it stop being a Agent-like Object.

2. To finally resolve the issue locally, i'm using patch-package.

I'm applying this patch:

diff --git a/node_modules/next-auth/core/lib/oauth/client.js b/node_modules/next-auth/core/lib/oauth/client.js
index 77161bd..1082fba 100644
--- a/node_modules/next-auth/core/lib/oauth/client.js
+++ b/node_modules/next-auth/core/lib/oauth/client.js
@@ -7,11 +7,19 @@ exports.openidClient = openidClient;
 
 var _openidClient = require("openid-client");
 
+var HttpsProxyAgent = require("https-proxy-agent");
+
 async function openidClient(options) {
   const provider = options.provider;
-  if (provider.httpOptions) _openidClient.custom.setHttpOptionsDefaults(provider.httpOptions);
-  let issuer;
+  let httpOptions = {};
+  if (provider.httpOptions) httpOptions = { ...provider.httpOptions };
+  if (process.env.http_proxy) {
+    let agent = new HttpsProxyAgent(process.env.http_proxy);
+    httpOptions.agent = agent;
+  }
+  _openidClient.custom.setHttpOptionsDefaults(httpOptions);
 
+  let issuer;
   if (provider.wellKnown) {
     issuer = await _openidClient.Issuer.discover(provider.wellKnown);
   } else {

It would be great if this issue could be resolved in future versions!
Maybe with an option like "useProxyAgent" that, if true, the openidClient function will check that a "process.env.http_proxy" exists and, if so, sets an HttpsProxyAgent like in my patch?

Anyway, in case anyone else has the same problem as i, i hope the patch can help! :)

Thanks!

[michaelbird1155]

Thanks for the solution @raphaelpc. Being behind a corporate proxy has a lot of pains - this being one of them. I apreciate the workaround and look forward to a minor update including support for proxy settings. Hopefully soon! :D

[davesag]

Maybe with an option like "useProxyAgent" that, if true, the openidClient function will check that a "process.env.http_proxy" exists and, if so, sets an HttpsProxyAgent like in my patch?

I'd really want the exact environment variable to be configurable. Ideally just adding a proxy as an option to the provider configuration would be the answer

[imchao9]

+var HttpsProxyAgent = require("https-proxy-agent");
this one will have problem:
HttpsProxyAgent is not a constructor

use this one, the problem solve
+import { HttpsProxyAgent } from 'https-proxy-agent';

[Stephen-Ma-2023]

The problem is provider.httpOptions.agent is not type of HttpsProxyAgent. It was init in "src\core\init.ts" -> "src\core\lib\providers.ts" which using "src\utils\merge.ts" to merge the "rest" and "user options".
We set httpOptions(user options) in [...nextauth].ts with agent = new HttpsProxyAgent.
But in merge.ts, it can't copy entire class. We lost the class type HttpsProxyAgent, only enumerable properties was copied.

Is there anyone can fix this issue?
@balazsorban44 I am not sure, is it the reason for this case?

[balazsorban44]

Yeah. Unfortunately, this is not a priority right now as the use case seems to be uncommon enough, but I'm happy to keep this issue open as long as it doesn't get stale.

[davesag]

I'm working on a project internal to atlassian and in order to talk to their services we MUST run our requests through a whitelist proxy service. So while it might not be a common enough use-case for you, it's critical for us. We also have issues with having to patch, and maintain a patched version of Next Auth.

The solution I am now about to propose to our team is simply to not use next-auth but instead to simply hand-wire the auth interactions as it's probably easier.

But if you do have a road-map to allow proxies in next-auth I'd be very happy.

[OffBy0x01]

I can't understand why a proxy is considered an uncommon use case. Maintaining a patched version of next-auth frankly sucks - never a smooth process. Surely the maintainers can add httpsProxyAgent as an optional dependency & implement the fix suggested by @raphaelpc.

Unless I'm missing something, it seems like a very minor change that would significantly improve QoL for a subset of users building non-public applications.

[ThePaulMcBride]

I agree, around once per month a customer tries to signup to an app I run and their email scanner "claims" their sign in token. It is such a hassle to deal with that I just have to tell the customer that I can't support them.

[baptisteArno]

Happens for one of my user as well: https://cln.sh/F3pA8x

[ThePaulMcBride]

This is exactly the same issue my users was having. Unfortunately excluding the HEAD requests didn't fix anything.

Should we move this to a separate issues specifically for this?

[ndom91]

Yeah feel free to open a new issue or discussion. I did some more in-depth research on this topic here: #3900 (comment).

Turns out this isn't such a simple fix, there are two workarounds I was able to find that others have implemented so far. Opencollective waits for mousemove or touchstart, etc. type of user-input events before potentially invalidating the email link.

Ghost seem to put a setTimeout on the db call to deleting the invitation token for 10s. Meaning that if the email scannign service hits the email verification link, the BE would normally delete it, but if the user then also hits it within the next 10s, it will still be valid and let them through.

In addition, there are two small PRs open to add separate tutorials to the docs.

1. Block HEAD requests: https://github.com/nextauthjs/next-auth/pull/3900/files
2. Actually add support for an http agent to openid-client for real proxying: https://github.com/nextauthjs/next-auth/pull/3931/files

@baptisteArno thanks for the recording!

[baptisteArno]

Thank you guys for the clarification even though I still don't really understand what's wrong exactly.

My client is asking: "Would there be any way my IT team at BCREA could add Typebot as a safe IP address to bypass our firewall?" What should I say?

[ndom91]

Thank you guys for the clarification even though I still don't really understand what's wrong exactly.

My client is asking: "Would there be any way my IT team at BCREA could add Typebot as a safe IP address to bypass our firewall?" What should I say?

Hey so it looks like y'all are using outlook, right. Maybe you can add the typebot URL to this safelink allow list?

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/safe-links?view=o365-worldwide#do-not-rewrite-the-following-urls-lists-in-safe-links-policies

Also I noticed in your video that the tyepbot url, when initially clicked in the email, first gets routed through another url called "protect-us.mimecast.com". Is this a service your familiar with in your org? Maybe that's the one causing you this trouble.

[oldriv]

Hi @balazsorban44 I am wondering why the code from the patch simply not used in the codebase? I was considering making a PR but then found this discussion and am quite confused by recommendation to use a patch instead of implementing this fix in the framework.

[balazsorban44]

See #6763 (comment). We decided to keep this backwards-compatible, and utilize the NEXTAUTH_INTERNAL_URL instead, for this purpose.

[magicspon]

thanks for the quick response. is NEXTAUTH_INTERNAL_URL available in the latest version?

[magicspon]

I've added NEXTAUTH_URL_INTERNAL to my vercel env settings... still seeing the same issue.

[magicspon]

@balazsorban44 heyo... are we expecting this to have been resolved by? #6763

[drmartin1998]

I'll add to the "demand" for this. It seems there's a solution and several of us willing to issue a PR.

[coopernewby]

As a work around, I just replace the auth link that uses the OTP and instead send them to a /auth page and applies the OTP has the url of the button on the page. That way it does not expire and they can click it even behind a proxy. This solved our problems. it was a bit annoying.

export default function Verify() {
  const searchParams = useSearchParams();
  const [authLink, getAuthLink] = useState(searchParams.get('url') || '');
  const router = useRouter();
  const redirectUrl = getURL();

  return (
    <div className="bg-white shadow sm:rounded-lg">
      <div className="px-4 py-5 sm:p-6">
        <h3 className="text-lg font-medium leading-6 text-gray-900">
          Magic Link Login
        </h3>
        <div className="mt-2 max-w-xl text-sm text-gray-500">
          <p>
            Click the button below to login. This link only lasts for one click
            for security so if sends you back to the login page, send yourself
            another link
          </p>
        </div>
        <div className="mt-5">
          <Link
            href={authLink + '&type=magiclink&redirect_to=' + redirectUrl}
            className="inline-flex items-center justify-center border border-transparent bg-yellow-500 px-4 py-2 font-medium text-black hover:bg-yellow-200 focus:outline-none focus:ring-2 focus:ring-yellow-500 focus:ring-offset-2 sm:text-sm"
          >
            Proceed to Dashboard
          </Link>
        </div>
      </div>
    </div>
  );
}

[c-healey]

I have the same problem that sign in times out when behind a corporate firewall. I had to patch it per the instructions above. Please fix this for all your corporate users.

[pnwright84]

I have used the patch suggested above for version 4.22.1 but unfortunately I'm receiving the following message when I try to action the sign in:

[next-auth][error][SIGNIN_OAUTH_ERROR]
https://next-auth.js.org/errors#signin_oauth_error HttpsProxyAgent is not a constructor {
  error: {
    message: 'HttpsProxyAgent is not a constructor',
    stack: 'TypeError: HttpsProxyAgent is not a constructor\n' +
      '    at openidClient (...\\node_modules\\next-auth\\core\\lib\\oauth\\client.js:17:17)

"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
});
exports.openidClient = openidClient;

var _openidClient = require("openid-client");

var HttpsProxyAgent = require("https-proxy-agent");

async function openidClient(options) {
  const provider = options.provider;
  let httpOptions = {};
  if (provider.httpOptions) httpOptions = { ...provider.httpOptions };
  if (process.env.http_proxy) {
    let agent = new HttpsProxyAgent(process.env.http_proxy);
    httpOptions.agent = agent;
  }
  _openidClient.custom.setHttpOptionsDefaults(httpOptions);

  let issuer;
  if (provider.wellKnown) {
    issuer = await _openidClient.Issuer.discover(provider.wellKnown);
  } else {
    var _provider$authorizati, _provider$token, _provider$userinfo;

    issuer = new _openidClient.Issuer({
      issuer: provider.issuer,
      authorization_endpoint: (_provider$authorizati = provider.authorization) === null || _provider$authorizati === void 0 ? void 0 : _provider$authorizati.url,
      token_endpoint: (_provider$token = provider.token) === null || _provider$token === void 0 ? void 0 : _provider$token.url,
      userinfo_endpoint: (_provider$userinfo = provider.userinfo) === null || _provider$userinfo === void 0 ? void 0 : _provider$userinfo.url,
      jwks_uri: provider.jwks_endpoint
    });
  }

  const client = new issuer.Client({
    client_id: provider.clientId,
    client_secret: provider.clientSecret,
    redirect_uris: [provider.callbackUrl],
    ...provider.client
  }, provider.jwks);
  client[_openidClient.custom.clock_tolerance] = 10;
  return client;
}

[pnwright84]

I believe this is to do with the version of https-proxy-agent, I have downgraded to version 5.0.0 and now have a different error.

[next-auth][error][SIGNIN_OAUTH_ERROR]
https://next-auth.js.org/errors#signin_oauth_error expected 200 OK, got: 404 Not Found {
  error: {
    message: 'expected 200 OK, got: 404 Not Found',
    stack: 'OPError: expected 200 OK, got: 404 Not Found\n' +
      '    at processResponse

[imchao9]

I also have this problem!

[nhuethmayr]

The issue here is that some email scanners consume the activation code with their probing request. Its also typically a GET and not a HEAD request which makes that the often recommended code (below) does not work

import type { NextApiRequest, NextApiResponse } from "next"
import NextAuth from "next-auth"

export default async function auth(req: NextApiRequest, res: NextApiResponse) {

  if(req.method === "HEAD") {
     return res.status(200)
  }
  
  ...
}

A solution that works nicely (by @balazsorban44) can be found here
#4965 (comment)

[ghost]

I am very confused as to why this works in development but not in production. I am deploying Next.js to an openshift Kubernetes cluster and all is well until it is deployed to the cluster. All this working on the same machines that are behind the corporate proxy in development but production shuts it down immediately.

Is there nothing coming to fix this?

[SleeveShirtholes]

@anonwashere, did you get next-auth to work in Openshift?

[ghost]

Yes, I did, unfortunately it involves maintaining a patch to next-auth with patch-package by modifying /node_modules/next-auth/core/lib/oauth/client.js

The solution is here on the next-auth website.

I, however, have to build the containerized next app with .environment.production at build time by copying into linux layer and running npm run build with my environment variables available to the build process. This is because I could never figure out how to access environment variables set in openshift from the next app which has something to do with them being available at build time instead of runtime that I don't quite remember..

The reason I point this out is because for the resolution linked above, you will need to set http_proxy environment variable which I have available at build time to my next app, because it wouldn't be available to it from openshift, so I have no choice but to copy .env.production into the docker container itself.

Copying .env.production is okay for me because I work on internal applications that will never see the public internet and I'm locked well away from the public internet, so I'd be careful if that is something you do work on when implementing env variables with openshift and docker.

[g1eny0ung]

Hi, guys. I also encountered this problem and opened a PR (#9675) to try to fix it. Thanks @Stephen-Ma-2023's comment (#3944 (reply in thread)), I also think this is the core reason for this problem.

[g1eny0ung]

Refer to this link to get the patched solution due to this PR has been closed.