On every page refresh session is always false

[bmandl]

Hello guys,
I am new to next.js and I really started to like it. I am getting used to migrate from express.js routing to next.js api routing (kind of messy, but I am getting there). Now, I am developing simple calendar app, where I want to show login page, if user is not logged in, and calendar with events, if user is logged in. Now, everytime I refresh my page, I see a login page for a short period of time, then session gets populated and I can see my calendar page. Am I missing some optimization here or anything else? Here is snipped of my code:

import { signIn, signOut, useSession } from 'next-auth/client';

const Home = () => {
const [session, loading] = useSession();
return (
    <>
      {session
        ? (
          <div className="calendar-container">
            <Calendar
              selectable
              localizer={localizer}
              events={events}
              onSelectSlot={handleTimeSelect}
              onSelectEvent={handleEventClick}
            />
          </div>
        )
        : (
          <>
            Not signed in
            {' '}
            <br />
            <button onClick={signIn}>Sign in</button>
          </>
        )}
};
export default Home;

And my [...nextAuth].js file, just copied from example:

import NextAuth from 'next-auth';
import Providers from 'next-auth/providers';

const options = {
  // Configure one or more authentication providers
  providers: [
    Providers.GitHub({
      clientId: process.env.GITHUB_ID,
      clientSecret: process.env.GITHUB_SECRET,
    }),
    Providers.Google({
      clientId: process.env.GOOGLE_ID,
      clientSecret: process.env.GOOGLE_SECRET,
    }),
    // ...add more providers here
  ],

  // A database is optional, but required to persist accounts in a database
  // database: process.env.DATABASE_URL,
};

export default (req, res) => NextAuth(req, res, options);

So any ideas, why is this happening to me? What should I do to prevent that, so when I refresh my page, I see Calendar page, because I am already logged in.

[iaincollins]

Hi @bmandl,

If you add a file pages/_app.js like the one in the example project to your site, it should resolve this problem for you.

import { Provider } from 'next-auth/client'

// Use the <Provider> to improve performance and allow components that call
// `useSession()` anywhere in your application to access the `session` object.
export default function App ({ Component, pageProps }) {
  return (
    <Provider session={pageProps.session} >
      <Component {...pageProps} />
    </Provider>
  )
}

This will allow your client side rendered page to inherit the session data from the server side rendering pass, so that you don't see a flash of content intended for users who are not signed in.

It will also mean the session state is shared between other pages in your site, so when a user navigates to a new page on your site the client won't need to wait to check the session again before displaying the new page.

This is a scenario where Single Page Apps are able to be much more responsive to user input and feel faster than traditional web applications because they can take advantage of things like session state already being stored in memory on the client.

[iaincollins]

Update for folks below who have commented on this issue:

I strongly suggest trying out the example project which includes example pages that use both Client Side Rendering (CSR) and Server Side Rendering (SSR) and using it for reference:
https://next-auth-example.now.sh/

All the pages in the example use Client Side Rendering and the server page also uses Server Side Rendering, and so works without any client side JavaScript (with the trade off being page rendering speed):
https://next-auth-example.now.sh/server

The code to do this in harmony with Client Side Rendering is very simple, you can view the source here:
https://github.com/nextauthjs/next-auth-example/blob/main/pages/server.js

In the example site, you can see there is no flash of content going between pages (including between Client and Server rendered pages) or when refreshing any of the pages. On Client Side Rendered pages, there is a check performed that toggles showing the current signed in status only when it has been fetched from the server to avoid this.

You can find the conditional logic for this in the Header component. The example site uses CSS animation for the transition between not visible / visible states to improve the user experience.

You will likely want implement something similar; typical strategies for handling this gracefully in a Single Page Applications include displaying either no content or placeholder content in order to avoid a layout shift while session state is being loaded when the site is first visited in a new window or tab. Other to consider are ensuring a consistent height and alignment of text for both "signed in" and "not signed in" states (as well as any placeholder content).

Note: As per the demo, you won't see this change navigating between pages if _app.js is configured correctly; only when initially opening a site in a window or tab.

The approaches taken in the example project are applicable to handling authentication with any CSR / SSR strategy in any (and are not specific to NextAuth.js or even Next.js / React) and so can be helpful to understand and can be applied in other frameworks (e.g. Vue, Angular, etc).

[balazsorban44]

I think an also important point to make is where pageProps.session come from #1132

[osseonews]

Thanks for the great library and documentation. My question is related to the original question, which it doesn't seem is answered. If you put the Provider in pages/_app.js per the docs, then the useSession works if the user navigates the site. No problems. No flashes or anything. But, if the user actually refreshes the browser or opens a new tab, the user session is completely lost. This is not a good UI for various reasons. I assume this is because the session is just a "state" and all state is lost on a browser refresh or new tab? How do you keep maintain the session state even if some user actually refreshes the browser or even if they open another tab? I assumed useSession is reading the JWT, so the session should persist via new tabs etc. But apparently it is not. Please clarify. Thanks.

PS my example is as follows. The user logs in and the session is verified. Then the user opens a new browser tab, and the session becomes null, so they are not logged in. Also, if you go back to the first browser tab, after opening another tab, the session is null again and the user is logged out. So useSession only seems to work in one particular browser tab and only if you navigate within the site itself (never refreshing anything). This is not how most users use websites, though.

[alan-dx]

Thanks for the great library and documentation. My question is related to the original question, which it doesn't seem is answered. If you put the Provider in pages/_app.js per the docs, then the useSession works if the user navigates the site. No problems. No flashes or anything. But, if the user actually refreshes the browser or opens a new tab, the user session is completely lost. This is not a good UI for various reasons. I assume this is because the session is just a "state" and all state is lost on a browser refresh or new tab? How do you keep maintain the session state even if some user actually refreshes the browser or even if they open another tab? I assumed useSession is reading the JWT, so the session should persist via new tabs etc. But apparently it is not. Please clarify. Thanks.

PS my example is as follows. The user logs in and the session is verified. Then the user opens a new browser tab, and the session becomes null, so they are not logged in. Also, if you go back to the first browser tab, after opening another tab, the session is null again and the user is logged out. So useSession only seems to work in one particular browser tab and only if you navigate within the site itself (never refreshing anything). This is not how most users use websites, though.

I'm having the same problem when the user refreshes the browser. At first useSession returns null but later the session returns normally. This has been giving me some headaches.

[SagnikPradhan]

@iaincollins Weird issue, I have got a component and a page, session to seems to be always undefined in the component. But it works on the page. This is how my app component looks.

// _app.tsx
import { AppProps } from "next/app";
import { Provider as NextAuthProvider } from "next-auth/client";
import { GeistProvider, CssBaseline } from "@geist-ui/react";

const App: React.FC<AppProps> = ({ Component, pageProps }) => {
  return (
    <NextAuthProvider session={pageProps.session}>
      <GeistProvider>
        <CssBaseline />
        <Component {...pageProps} />
      </GeistProvider>
    </NextAuthProvider>
  );
};

export default App;

Never mind, Found the issue

[darrenbutcher]

@iaincollins Hey, encountering the same issue on page refresh with JWT (SSG/client-side). I notice a flash of my 'login' button even while authenticated in the header.

I also have the same setup for pages/_app.js as you mentioned & similar components setup from the example repo. As noted in the following screens, on refresh the session is always undefined & loading is always true, both when logged in & out. Tried to combat the flash, with a loading skeleton, however since loading is always true on refresh, I see the loading skeleton even when logged out.

I tested the output with
useEffect(() => { console.log(session, loading) }, [session])

Refresh while logged out:

Refesh while logged in:

I also tested this out with SSR with no issues but atm didn't want to opt in to SSR. Am I missing something or a concept on how this is suppose to work.

[kyds3k]

I'm seeing the same problem . . . was there ever a resolution for this? I am actually using SSR, but still seeing the flash. @darrenbutcher how did you implement it with SSR?

[darrenbutcher]

Good question, unfortunately I did not really test this extensively with SSR, so can't say to your case. In my initial minimal test, as I can recall I had no issues SSR (I didn't notice any flash), was only when I tried it client-side/SSG only).

Since the release of SSG in Next 9.4, the docs advise to only use SSR possibly as a last resort, so I have opted into that, which was one reason I was checking whether I was going in the right direction with implementing Next-Auth as I have only needed (SSG/client-side) so far. I have only picked up Next recently aswell, so I have been using the Vercel Dashboard as a jumping off point which is built with SSG.

It's a pity that none of the maintainers has given any advice on this matter, whether its the intended behavior or not, some direction would have been helpful.

I have since moved on from this but planning on coming back to this issue to work with an official "best practice" implementation to improve the UX. Good luck @kyds3k, you can let me know if you come up with anything on your end.

[iaincollins]

@darrenbutcher NextAuth.js shipps with a working example project at https://next-auth-example.now.sh that shows how to do both client and server side rendering without any flash when navigating between pages.

[oelbaga]

@darrenbutcher NextAuth.js shipps with a working example project at https://next-auth-example.now.sh that shows how to do both client and server side rendering without any flash when navigating between pages.

That example is not a completely reliable implementation related to this discussion because signed in or out it shows the "Protected" navigational link which would rarely be the case. Most are discussing hiding something when not logged in but still seeing a flash of It on a hard refresh. However, in the example the "Protected" link remains whether logged in or out so it's not solved for.

[drb1010]

please refresh the browser you will see the issue

[jotapee]

I'm facing the same issue, I had to switch to the getSession method instead.
After reloading the page the loading state stays forever, I have followed the example and my _app.js looks exactly like it, I'm calling the session on a <Header/> component.
The weird thing is that after refreshing it will completely hang up at least I click anywhere outside the document, eg: url bar, switching to another application, anything. That will immediately make the session work.

[jotapee]

I just found that out that the bug happens if you try to verify if the user is logged in on the _app.js file.

If you call either useSession or getSession there, it will behave weirdly if you call it from your components.

useSession example:

function MyApp({ Component, pageProps }) {
	const [session, loading] = useSesssion();

	return session ? (
		<Provider
			options={{
				clientMaxAge: 0,
				keepAlive: 0
			}}
			session={pageProps.session}
		>
			<Head>
				<link rel="icon" href="/images/favicon.png" />
			</Head>
			<Component {...pageProps} />
		</Provider>
	) : (
		<Login />
	);
}

If you call useSession() on any of your components, loading will be always true.

[Robert-OP]

Similar problem here trying to getSession in App.getInitialProps as below and pass the pageProps.session in the AuthProvider as in the examples above (and next-auth's documentation). To be noted that I have the session when I use the client-side hook useSession(), but not when I try to getSession(ctx) in App.getInitialProps, neither in getServerSideProps function on another page (basically getting the same error as below).

So, it works well when I work in development, but when I deploy it to Azure in a Docker container I get the following error:

2021-02-18T12:08:04.140106140Z [next-auth][error][client_fetch_error]
2021-02-18T12:08:04.140215540Z https://next-auth.js.org/errors#client_fetch_error https://beta.femaleinvest.com/api/auth/session FetchError: invalid json response body at https://beta.femaleinvest.com/api/auth/session reason: Unexpected token  in JSON at position 0
2021-02-18T12:08:04.140224040Z at /usr/next_app/node_modules/node-fetch/lib/index.js:272:32
2021-02-18T12:08:04.140239040Z at runMicrotasks (<anonymous>)
2021-02-18T12:08:04.140252040Z at processTicksAndRejections (node:internal/process/task_queues:94:5)

App.getInitialProps = async ({ Component, ctx, router }: AppContext) => {
  const localeFilter = { name: 'locale', value: router.locale.replace('-', '_') };

  const footerData = await getStrapiSingle('footers', { filter: localeFilter });
  const headerData = await getStrapiSingle('headers', { filter: localeFilter });
  const session = await getSession(ctx);

  let pageProps = {};

  if (Component.getInitialProps) {
    pageProps = await Component.getInitialProps(ctx);
  }

  let editorMode = process.env.EDITOR_MODE === 'true';

  return {
    pageProps: { ...pageProps, headerData, footerData, editorMode },
  };
};

[brunocrosier]

I believe I'm experiencing a similar issue.

I am using JWT with an otherwise unmodified next-auth-example setup

#704 (comment) is a really good explanation of what's happening - whenever I console.log the pageProps.session it will always be undefined unless getSession is called inside the page's getServerSideProps or getStaticProps

Could @iaincollins or @balazsorban44 confirm or comment on whether it's normal / expected behaviour for session to be undefined on client-side-rendered pages?

The only thing that fixed this for me was using the getInitialProps solution that @Robert-OP posted - but the downside to that is that it opts the whole site out of SSG.

Any input / advice would be greatly appreciated! 🙏

[brunocrosier]

Hey @iaincollins. Firstly - thanks for the speedy response, and for the fantastic library.

Essentially, I think what everyone in this discussion is trying to achieve here, is to access the session inside of _app.js, on both client-side and server-side rendered pages.

The reason for wanting to do so will be different for everyone, but my specific use-case is because I would like to pass the session to an <ApolloProvider>. It would look something like this

I have created an extremely bare-bones repo to demonstrate what's happening, by cloning next-auth-example. The only change I made was to add this code to the _app.js file

useEffect(() => {
    console.log(pageProps);
  }, [pageProps]);

The repo: brunocrosier/next-auth-example@30c9422#diff-c85e043f1db00b919581c615d87508f7d4ff2bb8058798ebbe475b4a6e087f26

The result is, the session is correctly logged to the console on the /server (which is what we want). I believe this is because we are calling getSession() inside the getServerSideProps of that page, and passing the session to the page.

The problem, however, is that session is logged to the console as undefined on / and /client (client-side rendered pages).

Essentially, this means that we cannot access session on CSR pages.

The only fix that I could find was to use this code to add getInitialProps inside _app.js, but this opts us out of SSG throughout the whole site.

Video demo showing the result: https://streamable.com/nxuoj9

Let me know if anything is unclear! Thank you in advance.

[iaincollins]

I think there are a few things to unpack here, but I think being really clear on if you want Server Side Rendering on all pages is a good starting point and I think that applies to other folks too. I think you have found the edges already though. :-)

1. Server Side Rendering on all pages

   If you really do want to access the session server side on all pages, you could need to add getInitialProps() in _app.js and take the performance hit on page speed.

   i.e. the approach in your fix is absolutely correct if you want to access the session server side on all pages.

   Conceptually it is impossible to access the session server side without actually running server side code and opting out of
   Static Site Generation (SSG).

2. Server Side Rendering on some pages

   If you want to access it on some pages you can use the approach of using getServerSideProps() on a per page basis, which you can abstract out to a wrapper if you want to avoid boilerplate.

   This will make those pages slower to render but other pages will stay fast.

3. Client Side Rendering only

   If you don't really need to access the session server side, you can put the ApolloClient in a regular React Component or HOC that you use in pages and use the provided useSession() hook to pass details from the session to it once the loading argument indicates the session state is loaded and the session object is ready.

   Of course, all client side calls to useSession() anywhere in an application should share the same session state using React Context (depending on the correct NextAuth.js provider configuration in _app.js) so triggering useSession() multiple times in an application across different Components does not invoke multiple requests from the client.

Some of the approaches here might also be helpful:
https://github.com/lfades/next-with-apollo

[brunocrosier]

Thanks @iaincollins for the really clear reply. That all makes perfect sense !

[sengho66]

I think there are a few things to unpack here, but I think being really clear on if you want Server Side Rendering on all pages is a good starting point and I think that applies to other folks too. I think you have found the edges already though. :-)

1. Server Side Rendering on all pages
   If you really do want to access the session server side on all pages, you could need to add getInitialProps() in _app.js and take the performance hit on page speed.
   i.e. the approach in your fix is absolutely correct if you want to access the session server side on all pages.
   Conceptually it is impossible to access the session server side without actually running server side code and opting out of
   Static Site Generation (SSG).
2. Server Side Rendering on some pages
   If you want to access it on some pages you can use the approach of using getServerSideProps() on a per page basis, which you can abstract out to a wrapper if you want to avoid boilerplate.
   This will make those pages slower to render but other pages will stay fast.
3. Client Side Rendering only
   If you don't really need to access the session server side, you can put the ApolloClient in a regular React Component or HOC that you use in pages and use the provided useSession() hook to pass details from the session to it once the loading argument indicates the session state is loaded and the session object is ready.
   Of course, all client side calls to useSession() anywhere in an application should share the same session state using React Context (depending on the correct NextAuth.js provider configuration in _app.js) so triggering useSession() multiple times in an application across different Components does not invoke multiple requests from the client.

Some of the approaches here might also be helpful: https://github.com/lfades/next-with-apollo

I don’t think anyone is having trouble calling the session, we are all facing the issue where if users are logged in they’ll see a brief flash if they reload the page that’s because on the client side the browser needs to check if there is a seasion first but however if this is used on SSR there won’t be any flash. How do we avoid the flash? The example you provided totally not helping.

[balazsorban44]

If you don't provide a session in getServerSideProps, you simply cannot avoid the flash. We have to get the session from somewhere, and cannot make it magically appear. Either you use getServerSideProps or work around by a better UX while loading. An idea is to use a Skeleton UI instead of spinners for the user.

[jonrosner]

In the code-comment of header.js it says: "and avoids any flash incorrect content on initial page load". When I reload the page on client-side I actually see for 1 second the Login button even when I am already logged in. What is meant by "flash incorrect content"?

Does this mean I HAVE to use SSR to avoid this? How would one build an application with next.js / next-auth and static pages that does not have this behavior of showing an incorrect state until the session is loaded?

[tons613]

It is recommended to use SSR to avoid flashes of incorrect state being loaded at the client side.

[miguelguadarrama]

Sorry I realize I better start a new discussion for this. I will leave the comment here for reference.

Hey, I have a semi-related comment to this.

In my app I use a component whenever the useSession()'s loading is true, set up in a wrapper layout component over the whole application in the _app.js file. Which in theory works perfectly because it will just show a loader one time and once the session is ready (e.g. loading === false) it will display the page accordingly to the session state.

The problem is, for some reason NextAuth likes to destroy the session at random times. I use Okta provider, and the timeout is set to 8 hours for the OpenID tokens. When the session destroy happens, the loading value becomes true again so my wrapper layout component shows the Loader component again for a few seconds. What I'm trying to understand is why NextAuth is destroying the session, even though the OpenID tokens (access tokens) still have hours before becoming invalid.

I also noticed in the NextJS console output this line whenever this happens:
event - build page: /api/auth/[...nextauth]
Which, could be the culprit. However, this also happened a few times in my deployed app. So not sure if it's related to fast refresh. Anyway what could be triggering a rebuild of nextauth backend component?

Hopefully someone has a similar issue or can provide some suggestions.

[balazsorban44]

Left my comment here: #2370 (comment) 😉

[TimMTech]

Vercel needs solid patching in regards to ALL of their tech. Too many customized work arounds. Unproductive and time consuming. Probably last time I use next.js for a very very long time. Triple the work with almost close to none performance boost.

[rolznz]

If you're developing locally with JWT enabled, make sure to set a NEXTAUTH_SECRET in your .env (see https://next-auth.js.org/configuration/options)

[profound-innovations]

Facing this issue even in 2023 with app router. When I reload a page, even when the user is signed in, it shows a flash of logged out screen and then shows the correct screen. Unsure what I am doing wrong.

[profound-innovations]

Thank you so much! With some minor tweaks this worked for us!

[sngstaff]

It's really worked, thx <3

[dany679]

I'm so upset this isn't in the doc ts

[sogeking7]

It is not working

[hiefs]

lunwingkit's solution worked for me! If youre using v5 or the beta for Auth.js the correction is
const session = await getServerSession(authOptions); should get changed to just
const session = await auth();

[0xJayden]

Try checking for the loading status AND the session provided by useSession like this

const { data: session, status } = useSession();

if (status !== "loading" && !session) return <AccessDenied />;

return <YourPage />

This way the AccessDenied component won't flash when loading/refreshing the page.

[Hamzaqurashii]

you are a gem bro, I was searching for a correct solution and didn't find anything anywhere. I was just bored and scrolling this page until I read this. This worked for me. Thanks a lot. 🥉

[sogeking7]

This is not solution, I mean who wants fake loading state