sidebase / nuxt-auth

🔐 Nuxt user authentication and sessions via authjs (next-auth), local and refresh providers. nuxt-auth wraps NextAuth.js to offer the reliability & convenience of a 12k star library to the nuxt 3 ecosystem with a native developer experience (DX)
https://sidebase.io/nuxt-auth/
MIT License
1.13k stars 134 forks source link

404 error calling getSession endpoint even if getSession is set to false #774

Open cccaballero opened 1 week ago

cccaballero commented 1 week ago

Environment


Reproduction

I set the following config:

auth: {
    baseURL: 'http://localhost:8000'
    provider: {
      type: 'refresh',
      endpoints: {
        signIn: { path: `/auth/login/`, method: 'post' },
        signOut: { path: `/auth/logout/`, method: 'post' },
        signUp: { path: `/auth/registration/`, method: 'post' },
        getSession: false
      },
      token: { signInResponseTokenPointer: `/auth/token/verify/` },
      refreshToken: { signInResponseRefreshTokenPointer: `/auth/token/refresh/` },
    }
  }

My backend is running in a different server (Django app) exposed in port 8000 and my frontend nuxt apllication is exposed in port 3001

Describe the bug

When the nuxt app loads, I get the following error:

404
[GET] "http://localhost:8000/api/auth/session?callbackUrl=http:%2F%2Flocalhost:3001%2F": 404 Not Found

Additional context

It looks like nuxt-auth is trying to call a session endpoint even though I'm setting getSession to false.

Logs

client.mjs:30 

       GET http://localhost:8000/api/auth/session?callbackUrl=http:%2F%2Flocalhost:3001%2F 404 (Not Found)
$fetchRaw2 @ ofetch.37386b05.mjs?v=8708b347:222
await in $fetchRaw2 (async)
$fetch2 @ ofetch.37386b05.mjs?v=8708b347:268
_fetch @ fetch.mjs?v=8708b347:6
await in _fetch (async)
getSession @ useAuth.mjs?v=8708b347:108
await in getSession (async)
(anonymous) @ plugin.mjs?v=8708b347:17
executeAsync @ index.mjs?v=8708b347:111
(anonymous) @ plugin.mjs?v=8708b347:17
(anonymous) @ client.mjs:30
executeAsync @ index.mjs?v=8708b347:111
setup @ client.mjs:30
(anonymous) @ nuxt.js?v=8708b347:137
fn @ nuxt.js?v=8708b347:214
runWithContext @ runtime-core.esm-bundler.js?v=8708b347:3089
callWithNuxt @ nuxt.js?v=8708b347:220
(anonymous) @ nuxt.js?v=8708b347:37
run @ reactivity.esm-bundler.js?v=8708b347:32
runWithContext @ nuxt.js?v=8708b347:37
applyPlugin @ nuxt.js?v=8708b347:137
executePlugin @ nuxt.js?v=8708b347:156
applyPlugins @ nuxt.js?v=8708b347:187
await in applyPlugins (async)
initApp @ entry.js:48
(anonymous) @ entry.js:66
Show 20 more frames
Show lessUnderstand this error
nuxt.js?v=8708b347:122 [nuxt] error caught during app initialization FetchError: [GET] "http://localhost:8000/api/auth/session?callbackUrl=http:%2F%2Flocalhost:3001%2F": 404 Not Found
    at async $fetch2 (ofetch.37386b05.mjs?v=8708b347:268:15)
    at async plugin.mjs?v=8708b347:17:61
    at async setup (client.mjs:30:36)
    at async applyPlugin (nuxt.js?v=8708b347:137:25)
    at async executePlugin (nuxt.js?v=8708b347:173:9)
    at async applyPlugins (nuxt.js?v=8708b347:187:5)
    at async initApp (entry.js:48:7)
cccaballero commented 5 days ago

I'm currently testing in version 0.8.0-alpha.2. When I call the signIn function with redirect: false included in the signInOptions parameter, I don't encounter the on-screen 404 error anymore (it is in the console log). However, the module still calls getSession and the token data obtained during signIn is cleared. Maybe this is because:

https://github.com/sidebase/nuxt-auth/blob/faa039b72da2c64d9c214f0502dea053c7a4ff84/src/runtime/composables/local/useAuth.ts#L81

This condition is not met because getSessionOptions is undefined but the token exists. As a result, the function execution continues but fails when trying to call the getSession endpoint, and the token value is cleared.

I don't need getSession at all, because my API is stateless and there is no session in the server side.

zoey-kaiser commented 4 days ago

Hi @cccaballero 👋

Thanks for the detailed outline of the issue and investigation! Would you be willing to open a PR to patch this? We can then look to include this inside the 0.8.0 release!