-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Next.js 13 app router support #568
Comments
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:
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
|
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 |
@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. |
Seems like this library handles the auth for the |
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. |
Coming from d51bf07 .... any progress? :) |
Any way I can help move this along? Looking to contribute. @kmjennison |
@kmjennison hi, how long it might take? |
Bump. Any progress or prognosis on when this feature will be supported/released? |
any update? |
We are still using page router as we have dependency on this package. |
You can switch to https://www.npmjs.com/package/next-firebase-auth-edge |
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
orlayouts
.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
andwithAuthUserTokenSSR
. As far as I understand, the new approach gets rid of thegetServerSideProps
,getStaticProps
, andgetInitialProps
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
andpages/api/logout.ts
should probably stay unchanged as the docs state thatpages/api/*
should remain unchanged: https://beta.nextjs.org/docs/upgrade-guide#migrating-from-pages-to-appIs this a breaking change?
I think yes it's probably a breaking change.
The text was updated successfully, but these errors were encountered: