Next.js 13 app router support
MartinXPN opened this issue · 19 comments
The problem
A new version of Next.js was released recently: https://nextjs.org/blog/next-13
It introduces several new concepts and ways of writing Next.js apps with sever-components in mind. In this new release, the data fetching operations are supposed to happen in pages or layouts.
This introduces a new way of addressing auth state in the whole app. We can finally have the auth state in the global layout.tsx and share it across all the pages of the app.
Yet, this library currently sets the auth state on the server side through getServerSideProps and withAuthUserTokenSSR. As far as I understand, the new approach gets rid of the getServerSideProps, getStaticProps, and getInitialProps making the current authentication approach incompatible.
Describe the solution you'd like and how you'd implement it
I'm not sure about the implementation, to be honest. Yet, I'd love to have a way of accessing the auth state on the server.
My biggest use case would be to have the auth state inside the global layout: app/layout.tsx.
This will enable us to share the auth state across the whole app and not have export const getServerSideProps = withAuthUserTokenSSR() statements on several pages.
As an implementation detail, I think the pages/api/login.ts and pages/api/logout.ts should probably stay unchanged as the docs state that pages/api/* should remain unchanged: https://beta.nextjs.org/docs/upgrade-guide#migrating-from-pages-to-app
Is this a breaking change?
I think yes it's probably a breaking change.
Thanks for the issue! Input on design very much welcome. I'll be digging into this more as soon as I can make the time.
At a glance, there's built-in cookie access in server components: https://beta.nextjs.org/docs/api-reference/cookies#. However, this doesn't yet include write support:
Note: The Next.js team at Vercel is working on adding the ability to set cookies in addition to the cookies function. For now, if you need to set cookies, you can use Middleware.
So, implementation probably includes (or is exclusively) middleware. Related issue: #418
My guess is this won't require a breaking change in this library because Next.js is supporting incremental adoption of the new app structure. We should be able to keep the existing APIs for "legacy" pages.
Edit to add: the beta Next.js docs have a section titled "Authentication" that has not yet been filled in. I'm guessing more guidance to come.
I asked the Next.js team for the estimates regarding the Authentication guide on their beta docs. Here is a reply from Delba de Oliveira:
We're planning to make the "Build your application" and "API Reference" sections more stable first before moving to guides.
Thank you for sharing the issue above, I've added it to our docs roadmap for tracking. In the mean time, the recent commits on the next-auth repo may provide some guidance: https://github.com/nextauthjs/next-auth/commits/main
Seems like these commits might be relevant:
Is it a fair assumption to make that firebase authentication will not work with next.js 13?
It does work with nextjs 13 in general. But it does not work with react server components and the new app folder.
Your setup with the pages folder, SSR and so on should still work.
@kmjennison https://github.com/vercel/nextjs-mysql-auth-starter
This auth starter does it well
I could not for the life of me get getUserFromCookies to work without passing in the req/res
I tried to read the src for it but my head spun (not clever enough, myself to make it work)
Should I try to make an example repo people can work from to get next13 working in the app directory?
Not sure how the context and such will work, though
I re-built v1 canary with useRouter from next/navigation which seems to get router errors to go away
However, it does not return a valid user upon successful login on the /api/login enpoint, the user from setAuthCookies is just null for some reason
getUserFromToken does retrieve this value successfully from a layout file, but it's obviously not the value we would want
Do you have a working demo for next13 yet?
Would you want me to make a sandbox showing the above behavior?
@seanaguinaga Yes, please feel free to share any code snippets or demo apps here. We don't yet have a demo for the new app directory layout in Next 13, but as noted above, this library continues to work on pages outside of the app directory.
Is there any update regarding a demo app with the app dir and firebase auth?
Lots of things in next13 app directory is still in dev :P tried it out.. time to switch back and wait ☕
The biggest blocker for me at this point is the authentication part.
I've figured out how to use MUI with emotion, localization, and some other things. So, as soon as the auth with Firebase is supported I can start using the /app directory.
Seems like this library handles the auth for the app directory: https://github.com/ensite-in/next-firebase-auth-edge
The examples seem to demonstrate that it can also work on the server - not only on edge through middleware.
Now that app router is stable I believe new users will be increasingly looking to add firebase on top of boilerplates made with app directory. Could next-firebase-auth incorporate the edge and app learnings of next-firebase-auth-edge and get beta support out to capture this growing segment? I am worried about momentum growing there and this community getting fragmented/deprecated.
Hi, I'm planning on migrating to the app folder in the upcoming months.
Is this still a WIP or should I plan on changing lib?
Thanks!
Any way I can help move this along? Looking to contribute. @kmjennison