The latest updates on your projects. Learn more about Vercel for Git ↗︎

There is a tangent situation, which I didn't mention in my original bug report: if there really is a proxy.

We have two apps that connect to the same backend api (where [...nextauth].ts is located), and access it using nextjs's rewrite on the two apps, which behaves as a proxy and has the x-forwarded-host header.

///next.config.js in app1 and app2
module.exports = {
   rewrites() {
      return [
          {source: "/api/:path*", destination: `${process.env.API_URL}/api/:path*` }
      ]
   }
};

Our architecture is like this:

+-------------------------+     +--------------------------------+
| app1.com/api/auth       | ->  |     api.backend.com/api/auth   | 
+-------------------------+     |                                |
                                |                                |
+-------------------------+     |                                |
|  app2.com/api/auth      |  -> |                                |
+-------------------------+     +--------------------------------+
 

So for each request, we need to know which of the two apps the request came from so that next-auth will redirect back to the correct one. In this particular case, the x-forward-host header is actually very useful, except when the request comes from an oauth callback.
I currently have to detect the x-forwarded-host header AND the next-auth.callback-url cookie THEN set NEXTAUTH_URL explicitly.

If this PR were changed slightly to pull the pathname from NEXTAUTH_URL if it exists, and also took the callback url in cookie into account, next-auth's long standing request for a dynamic NEXTAUTH_URL would be satisfied

@Naddiseo Just reading through it, I think the callback url in that cookie is set based on the return value of detectHost. It's unclear to me what changes would be required to accomplish what you are trying to do in a way that doesn't break our use case, which is to proxy the entire Vercel deployment. One way or another, the callbackUrl will either need be set from NEXTAUTH_URL or x-forwarded-host.

In your case, you want it to be set by x-forwarded-host, because you want it to return your user to the same app URL they arrived on. In our case, x-forwarded-host refers to a URL that we never want the user to directly visit (which is the point of the NEXTAUTH_URL according to the documentation). It's unclear to me how we resolve those two goals which are in conflict with this PR.

@jjorissen52, I think I understand what you're saying: In a non-proxy environment the x-forwarded-host refers to the deployment url instead of the assigned domain? In which case, I see what you're saying about my use case being at odds.

I think I may have originally misunderstood how/what the x-forward-host actually was, because how it works, works in our favour if it also picked up the custom pathname something like:

if (process.env.VERCEL) {
    if (process.env.NEXTAUTH_ENV) { // http://example.com/custom/api/auth/path
        const {pathname} = new URL(process.env.NEXTAUTH_ENV);
        return `${forwardedHost}${pathname}`; // forwarded.com/custom/api/auth/path
    }
    return forwardedHost
}

Given that, I do think this PR is the correct fix in that it makes the code match what the documentation says it'll do.

For reference, how we're solving the multi app issue is something like:

/// [...nextauth].ts
export default (req,res) =>{ 
    const forwardedHost = req.headers['x-forwarded-host'];
    const callbackUrl = req.cookies['next-auth.callback-url'];
    const baseUrl = isAllowedUrl(forwardedHost)
        ? forwardedHost 
        : isAllowedUrl(callbackUrl) 
            ? callbackUrl
            : undefined;
    assert(typeof baseUrl !== "undefined");
    const url = new Url(baseUrl);
    url.pathname = "/custom/api/auth";
    
    process.env.NEXTAUTH_URL = url.toString();

    
    return NextAuth(req,res, { ...options});
}

Yes, you seem to understand the issue now. And that code snippet is very interesting. We hadn't considered making modifications like yours. We might be able to do something similar...

@Naddiseo We haven't had a chance to completely verify that this fixes our problem (I will come back with an update) but it looks like it works in the preview deployment this fixes the problem for us:

export default (req, res) => {
  /* next-auth prioritizes x-forwarded-host over NEXTAUTH_URL
    when running in Vercel https://github.com/nextauthjs/next-auth/pull/4509 .
    We need that to not happen, since the actual domain from *our* nginx proxy will differ
    from x-forwarded-host set by Vercel's proxy. E.g.:
      1. Our Nginx listening on example.dev proxies staging.example.com
      2. Vercel's Nginx listening at staging.example.com sets x-forwarded-host to staging.example.com
      3. next-auth will now set redirect_uri to staging.example.com instead of example.dev
  */
  if (process.env.VERCEL) {
    // prefer NEXTAUTH_URL, fallback to x-forwarded-host
    req.headers["x-forwarded-host"] = process.env.NEXTAUTH_URL || req.headers["x-forwarded-host"]
  }
  return NextAuth(req, res, options) // eslint-disable-line new-cap
}

Since x-forwarded-host is prioritized by next-auth in detectHost, you can control the callback URL by setting x-forwarded-host manually.

It looks like this issue did not receive any activity for 60 days. It will be closed in 7 days if no further activity occurs. If you think your issue is still relevant, commenting will keep it open. Thanks!

To keep things tidy, we are closing this issue for now. If you think your issue is still relevant, leave a comment and we might reopen it. Thanks!

Please re-open this, thanks.