404 not found route raises redirection to home / when globalAppMiddleware: true

[agracia-foticos]

Environment

• Operating System: Linux
• Node Version: v20.19.5
• Nuxt Version: 3.19.3
• CLI Version: 3.29.3
• Nitro Version: 2.12.9
• Package Manager: [email protected]
• Builder: -
• User Config: -
• Runtime Modules: -
• Build Modules: -

Reproduction

When i put globalAppMiddleware: true in nuxt.config.ts, when i go to wrong slug that would raise 404 page, redirects to home / page

If i delete globalAppMiddleware: true, a wrong slug goes to 404 page

Describe the bug

When i put globalAppMiddleware: true in nuxt.config.ts, when i go to wrong slug that would raise 404 page, redirects to home / page

If i delete globalAppMiddleware: true, a wrong slug goes to 404 page

Additional context

No response

Logs

[phoenix-ru]

@agracia-foticos Do you by any chance have authentication enabled for an error page? Do you use error.vue?

[agracia-foticos]

@agracia-foticos Do you by any chance have authentication enabled for an error page? Do you use error.vue?

I use error.vue in my app... in error.vue i dont put anything related with auth

[phoenix-ru]

Can it be the case that your application somehow matches the route? Based on the logic we have: https://github.com/sidebase/nuxt-auth/blob/b955bea35d015cf798f10e107b8d0cb75b489fa9/src/runtime/middleware/sidebase-auth.ts#L74-L89

you should always see a 404 page, and not be directed to a sign-in route.

Can you please inspect if the return from the code above actually happens for your application? For instance, by applying a pnpm patch @sidebase/nuxt-auth:

  const globalAppMiddleware = authConfig.globalAppMiddleware
  if (globalAppMiddleware === true || (typeof globalAppMiddleware === 'object' && globalAppMiddleware.allow404WithoutAuth)) {
    const matchedRoute = to.matched.length > 0
+   console.log('matched', matchedRoute)
    if (!matchedRoute) {
      // Hands control back to `vue-router`, which will direct to the `404` page
      return
    }
  }

I am suspecting that either to.matched has a match (e.g. a wildcard route or something else), or that there's other middleware which interferes

[agracia-foticos]

I have changed my code

matched true

[phoenix-ru]

That is the thing - there's something which matches your route, so it's not a 404 error anymore. What if you add another test Nuxt route middleware which simply logs the to.matched.length?

export default defineNuxtRouteMiddleware((to) => {
  console.log('hasMatched', to.matched.length > 0)
})

Would it still match on the problematic route you are trying to reach with globalAppMiddleware: true. Would it reach with false?

[agracia-foticos]

Can it be the case that your application somehow matches the route? Based on the logic we have:

nuxt-auth/src/runtime/middleware/sidebase-auth.ts

Lines 74 to 89 in b955bea

/** * We do not want to enforce protection on 404 pages (unless the user opts out of it by setting allow404WithoutAuth: false). * * This is to: * - improve UX and DX: Having to log-in to see a 404 is not pleasant, * - avoid the Error [ERR_HTTP_HEADERS_SENT]-error that occurs when we redirect to the sign-in page when the original to-page does not exist. Likely related to https://github.com/nuxt/framework/issues/9438 * */ const globalAppMiddleware = authConfig.globalAppMiddleware if (globalAppMiddleware === true || (typeof globalAppMiddleware === 'object' && globalAppMiddleware.allow404WithoutAuth)) { const matchedRoute = to.matched.length > 0 if (!matchedRoute) { // Hands control back to vue-router, which will direct to the 404 page return } } you should always see a 404 page, and not be directed to a sign-in route.

Can you please inspect if the return from the code above actually happens for your application? For instance, by applying a pnpm patch @sidebase/nuxt-auth:

const globalAppMiddleware = authConfig.globalAppMiddleware if (globalAppMiddleware === true || (typeof globalAppMiddleware === 'object' && globalAppMiddleware.allow404WithoutAuth)) { const matchedRoute = to.matched.length > 0

• console.log('matched', matchedRoute) if (!matchedRoute) { // Hands control back to vue-router, which will direct to the 404 page return } } I am suspecting that either to.matched has a match (e.g. a wildcard route or something else), or that there's other middleware which interferes

With this code now works, redirect me correctly to error page, not to home!!!

Can you apply the fix to the project!

[phoenix-ru]

With this code now works, redirect me correctly to error page, not to home!!! Can you apply the fix to the project!

Not sure what changed for you? Did adding a simple console.log resolve the problem? Then it is likely a result of some other action you did (e.g. moving a page/changing your middleware/updating Nuxt/etc.)

[OlePc]

I had a similar issue, and found that I actually had to set allow404WithoutAuth to false for it to work. I think it's related to this statement not making a lot of sense: https://github.com/sidebase/nuxt-auth/blob/a34eff12640727056d06d3c2da6dc8ec70845aba/src/runtime/plugin.ts#L44

Why is requireAuthOnErrorPage true when allow404WithoutAuth is true? The naming is contradictory. Or am I missing something?

[phoenix-ru]

requireAuthOnErrorPage

Hi @OlePc , true, the naming is wrong, but the intent seems to be correct:

shouldFetchSession = !(isErrorUrl && allow404WithoutAuth)	isError = true	isError = false
allow404WithoutAuth = true	✅ false	✅ true
allow404WithoutAuth = false	✅ true	✅ true

The only case when session should not be checked on a 404 page is when allow404WithoutAuth = true, i.e. when 404 is allowed to be without authentication (the default value). So I am not sure why it works for you in the opposite direction, what does "for it to work" mean in your case - is the 404 now unprotected as intended?