sidebase
Creating Server Components Causes an Error
Environment
- Operating System: Linux
- Node Version: v18.18.2
- Nuxt Version: 3.11.1
- CLI Version: 3.11.1
- Nitro Version: 2.9.6
- Package Manager: [email protected]
- Builder: -
- User Config: modules, css, tailwindcss, runtimeConfig, app, image, routeRules, devtools
- Runtime Modules: @pinia/[email protected], @sidebase/[email protected], @nuxtjs/[email protected],
- Build Modules: -
Reproduction
- Install NuxtAuth
- Make a server component or page by appending server to the name
Test.server.vue - Refresh and find /api/auth/session 500 error
Describe the bug
When trying to create a server component or a NuxtIsland by adding server to a page or component
Test.server.vue
You get the following error on the server
Server Error [GET] "http://localhost/api/auth/session?callbackUrl=http:%2F%2Flocalhost%2F__nuxt_island%2FTest_zILZnACY7W.json": <no response> fetch failed
Additional context
No response
Logs
No response
Hi @Plinpod 👋
We have not added support for Server components yet. I assume that we will need to add support for this by accessing the session via getServerSession. I assume the error you are experiencing is due to the component trying to access the client side session, which is not set on the server.
Due to this, I will categorize this as a feature request, rather than a bug. As mentioned above, I assume we will need to add a new composable that lets you access the server side session in server components.
I think adding support for this would be super cool, but also a bit tricky. Therefore, I will add this prioritize this feature a bit lower. As a workaround, could you try and categorize all authentication related logic inside the server component as a Client Component that does not get rendered on the server?
Hi @agracia-foticos 👋
We have yet to prioritize looking into this issue. I have some assumptions (primarily resting on many core functions of the module requiring access to the client, e.g., cookies & session data).
Looking into server components, I could also see that the fetch requests made to and by them differ from client components, which makes me assume that some code (e.g., the middleware cannot correctly execute on it).
Our current plan is to begin now working on the transition from using NextAuth under the hood to authjs, which requires substantial rewrites as the packages differ from one another. Therefore, I would like to avoid investigating this issue with the current NextAuth-based authentication, as changes in the underlying dependencies may require completely different fixes.
However, if you would like to spend some time investigating this and manage to find a solution, we would be happy to release a minor / patch version beforehand depending on the size of the changes. However sadly, our core team cannot dedicate any time to a full investigation at the moment.
I had a quick look into this issue and I believe I can pinpoint the required steps to support server-side components:
The issue is that the client-side composables are based on the client functions provided by AuthJS. These composables therefore require the client to be set to properly execute requests.
If we were to support server-side components, we would need to write a new implementation for them, that would follow the logic we currently use for the server-side session access methods such as getServerSession.
Inside this composable we would need to:
- Get the
baseURLof the API - Set the correct headers to include the authenticated users JWT Token
- Make the requests to the dedicated Rest API included with the AuthJS provider.
As this requires a bit more work, I think we will need to depriotize this feature. However, as a work-around you could build the logic I outlined above yourself!
When using the authjs provider, a set of API routes are automatically added and accessible. You could use $fetch to request data from their routes, to access the session inside a server component: https://auth.sidebase.io/guide/authjs/server-side/rest-api. These API routes also already automatically determine the JWT session token themselves, so requesting them should already result in the session being returned (however, I am not 100% sure of this!).
E.g.
const session = useFetch(`${baseURL}/session`, {
...options
})