Kinde•2w ago

How to handle root redirect before Auth and i18n case

Hello, I'm pretty stuck on trying to handle multiple things at the same time in the middleware. My stack is NextJS 15, next-international, Kinde. my folder structure is like this:

src/app/
    └── [locale]/
        ├── (auth)/
        │   └── wallets/
        └── (non-auth)/
            └── landing/

src/app/
    └── [locale]/
        ├── (auth)/
        │   └── wallets/
        └── (non-auth)/
            └── landing/

My goal is to protect everything in auth and allow users to freely access landing page while still being able to handle i18n * accessing localhost:3000/wallets - everything works fine, auth works, i18n works * accessing localhost:3000/en/landing - everything works fine, no auth needed * when I access localhost:3000 my expectation is that traffic is redirected to /app/landing (same as localhost:3000/en/landing) and no auth would be needed. Unfortunately localhost:3000 pops auth window. When user is logged in, it redirects properly to localhost:3000/en/landing Question is, what I am doing wrong that when I am not auth localhost:3000 is not redirecting properly and requries auth

// middleware.ts
const I18nMiddleware = createI18nMiddleware({
  locales: ['en', 'pl'],
  defaultLocale: 'en',
  urlMappingStrategy: 'rewrite'
});

const publicPaths = [
  "/en/landing",
  "/pl/landing",
  "/api/auth/setup",
  "/api/auth/login",
  "/api/auth/callback",
  "/api/auth/logout"
];


export default withAuth(
  async function middleware(req: NextRequest) {
    let locale = await getCurrentLocale()
    // Redirect from root path to locale-specific public page
    if (req.nextUrl.pathname === '/') {
      req.nextUrl.pathname = `/${locale??='en'}/landing`;
      return NextResponse.rewrite(req.nextUrl);
    }

    // Otherwise, handle authentication and i18n as normal
    return I18nMiddleware(req);
  },
  {
    publicPaths
  }
);

export const config = {
  matcher: [
    '/((?!api|_next/static|_next/image|favicon.ico).*)'
  ]
};

// middleware.ts
const I18nMiddleware = createI18nMiddleware({
  locales: ['en', 'pl'],
  defaultLocale: 'en',
  urlMappingStrategy: 'rewrite'
});

const publicPaths = [
  "/en/landing",
  "/pl/landing",
  "/api/auth/setup",
  "/api/auth/login",
  "/api/auth/callback",
  "/api/auth/logout"
];


export default withAuth(
  async function middleware(req: NextRequest) {
    let locale = await getCurrentLocale()
    // Redirect from root path to locale-specific public page
    if (req.nextUrl.pathname === '/') {
      req.nextUrl.pathname = `/${locale??='en'}/landing`;
      return NextResponse.rewrite(req.nextUrl);
    }

    // Otherwise, handle authentication and i18n as normal
    return I18nMiddleware(req);
  },
  {
    publicPaths
  }
);

export const config = {
  matcher: [
    '/((?!api|_next/static|_next/image|favicon.ico).*)'
  ]
};

Would really appreciate help as it looks I've fallen into some antipattern and cannot see through the tunnel vision 🙂

3 Replies

Ages•2w ago

Hi, Thank you for reaching out. It appears the core issue is that the middleware’s redirect logic for the root path ("/") is wrapped by the authentication handler. Consequently, unauthenticated requests to "/" are intercepted by the auth logic before the redirect can execute, which triggers the auth window instead of simply rewriting the URL to the locale-specific landing page (e.g., "/en/landing"). In other words, while your intention is for "/" to immediately rewrite to a public page like "/en/landing," the current middleware configuration forces "/" to be processed by the authentication check first. I will reproduce the same scenarios on my end to verify the behavior and see if any ordering nuances need to be adjusted. Once I confirm the exact behavior locally, I’ll be in a better position to suggest a precise fix.

darth0s😺OP•2w ago

hi, thanks for that initial guidance. It make me think about the <AuthProvider>. Maybe the wrapper children is too high. Would appreciate results of your investigation 🙂 I noticed 1 more thing. Console.log here fires only when I am logged in. So this might mean that I have to pull redirect outside the withAuth function.

export default withAuth(
  async function middleware(req: NextRequest) {
    let locale = await getCurrentLocale()
    // Redirect from root path to locale-specific public page
    console.log(`pathname: ${req.nextUrl.pathname}`)

    if (req.nextUrl.pathname === '/') {
      req.nextUrl.pathname = `/en/landing`;
      return NextResponse.rewrite(req.nextUrl);
    }

    // Otherwise, handle authentication and i18n as normal
    return I18nMiddleware(req);
  },
  {
    publicPaths
  }
);

export default withAuth(
  async function middleware(req: NextRequest) {
    let locale = await getCurrentLocale()
    // Redirect from root path to locale-specific public page
    console.log(`pathname: ${req.nextUrl.pathname}`)

    if (req.nextUrl.pathname === '/') {
      req.nextUrl.pathname = `/en/landing`;
      return NextResponse.rewrite(req.nextUrl);
    }

    // Otherwise, handle authentication and i18n as normal
    return I18nMiddleware(req);
  },
  {
    publicPaths
  }
);

Ages•5d ago

Hi, Thanks for sharing those details and your observations. Your findings confirm that the root redirection logic isn’t firing for unauthenticated requests because the withAuth wrapper intercepts them before your middleware can run. This means that unauthenticated users hitting "/" are getting caught by the auth check and redirected to the login flow before your custom redirect logic can execute. To address this, you’ll need to move the root redirect logic outside of the withAuth wrapper so that it executes first. For example, you could create a separate middleware that only handles the root redirect (and perhaps i18n), and then apply the auth middleware on the remaining routes. Here’s one approach: 1. Create a middleware file (or function) that checks if the request URL is "/" and rewrites it to your locale-specific landing page (e.g., "/en/landing"). This middleware should run before the auth middleware. 2. If you need to combine the logic, consider conditionally applying withAuth only when the request isn’t for the root path. That way, your redirect logic can trigger without interference. For example, you might restructure your middleware like this: https://snippet.host/baecmx In this example, the root redirect logic is placed before any authentication logic. This way, unauthenticated users accessing "/" will be redirected as intended, while other routes continue to benefit from both i18n and auth. I hope this clarifies the approach. Please let me know if you have any further questions or need additional assistance

Gaming

Programming

How to handle root redirect before Auth and i18n case

Did you find this page helpful?