Issue: Middleware Conflicts in auth.js Preventing Subdomain Redirects on Production

[ajzyn]

Description: I encountered a persistent issue while using auth.js in a Next.js application that involves session management across multiple subdomains. My application architecture relies on subdomain routing (e.g., supplier.myapp.com), with redirects handled via middleware. In the local environment, everything works great; however, in the production environment, I experienced the following issues:

Subdomain Redirects Fail with Session Cookie

When a user attempts to access a subdomain (e.g., supplier.myapp.com), the redirect does not work, resulting in a 504 error. After investigation, I found that removing the session cookie (session-token) allowed the subdomain rewrite to work correctly, suggesting a conflict between the session cookie handling and auth.js's middleware.

Custom Middleware Resolves the Issue

As a workaround, I replaced the auth.js middleware with custom middleware that checks for the session cookie (session-token) directly. This custom middleware successfully reads the session on subdomains and allows the redirect logic to function as expected on production, confirming that the problem originates specifically from auth.js’s middleware.

Steps to Reproduce:

1. Set up auth.js middleware to handle authentication and session management across subdomains.
2. Attempt to access a subdomain in a production environment with a valid session-token cookie.
3. Observe that the redirect fails (504 error) with auth.js middleware.
4. Remove the session cookie and notice that the redirect works as expected.
5. Replace auth.js middleware with custom middleware that directly checks for session-token without using auth.js, and observe that subdomain redirection now functions properly, with the session accessible on subdomains.

Expected Behavior

The auth.js middleware should allow seamless subdomain redirection and session handling across subdomains in the production environment without interfering with the redirect logic.

Actual Behavior

With auth.js middleware, redirects to subdomains fail when a session cookie (session-token) is present, resulting in a 504 error. Removing the session cookie or bypassing auth.js middleware resolves the issue.

Environment:

• auth.js version: 5.0.0-beta.25
• Next.js version: 14.2.16
• Database: PostgreSQL on Vercel with Neon adapter
• Deployment Platform: Vercel

Possible Cause

It appears that auth.js middleware may be interfering with cookie handling or redirect logic in a way that conflicts with custom subdomain routing, especially when session cookies are involved.

---

Configurations:

Simplified middleware:

export default auth((request) => {
  const hostname = request.headers.get('host')
  const domain = process.env.NEXT_PUBLIC_DOMAIN

  // Clone the URL to manipulate the path
  const url = request.nextUrl.clone()

  console.log('Incoming request for:', hostname, 'Path:', url.pathname)

  // Check if the domain variable is set correctly
  if (!domain) {
    console.error('NEXT_PUBLIC_DOMAIN is not defined')
    return NextResponse.next()
  }

  // Handle auth paths separately
  if (url.pathname.startsWith('/auth/')) {
    console.log('Auth path detected, bypassing rewrite:', url.pathname)
    return NextResponse.next()
  }

  // Redirect main domain to /site
  if (hostname === domain) {
    console.log('Redirecting main domain to /site')
    url.pathname = '/site'
    return NextResponse.rewrite(url)
  }

  // Rewrite subdomain to specific path
  const subdomain = hostname?.split(`.${domain}`)[0]?.toLowerCase()
  console.log('Subdomain detected:', subdomain)

  if (subdomain === 'supplier') {
    console.log('Rewriting supplier subdomain to /supplier')
    url.pathname = '/supplier'
    return NextResponse.rewrite(url)
  }

  // Continue with the original request if no conditions are met
  console.log('No rewrite or redirect needed, continuing with the original request')
  return NextResponse.next()
})

Auth.js config:

export const { handlers, signIn, signOut, auth } = NextAuth({
  adapter: PrismaAdapter(prisma),
  providers: [Google, Github],
  cookies: {
    sessionToken: {
      name: 'session-token',
      options: {
        httpOnly: true,
        sameSite: 'lax',
        path: '/',
        secure: process.env.NEXTAUTH_URL?.includes('https'),
        domain: process.env.NODE_ENV === 'production' ? '.${process.env.NEXT_PUBLIC_DOMAIN}' : '.myapp.local'
      }
    }
  },
  session: {
    updateAge: 15 * 60,
    maxAge: 60 * 15,
    strategy: 'database'
  },
  callbacks: {
    async session({ session, user }) {
      session.user = {
        id: user.id,
        email: user.email,
        name: user.name,
        type: user.type
      }
      return session
    }
  },
})

This issue affects any application structure that relies on subdomain-based access control or routing logic and uses auth.js middleware for session management ( auth.js stragetegy = 'database' ).