Upon reviewing the documentation on session verification in SSR (https://supertokens.com/docs/thirdpartyemailpassword/nextjs/session-verification/in-ssr), I noticed that the example code provided (https://github.com/supertokens/next.js/blob/canary/examples/with-supertokens/pages/index.tsx#L185-L187) utilises

SessionAuth

. I am unsure if the inclusion of

SessionAuth

is a requirement in a Next.js application. My aim is to circumvent the use of

SessionAuth

as it tends to render an empty page when

session.loading

is set to

true

, leading to an undesirable flickering effect. Given that pages in a Next.js application are capable of receiving session information from

getServerSideProps()

, it would seem reasonable to assume that we could verify a user's valid session as the server serves the initial page. (I wish to note that a client program should be in place to redirect and instigate server access when

signOut()

is invoked client-side.) My primary concern lies in the area of security. Is there any potential security risk when a page necessitates a session in Next.js but does not include

SessionAuth

? My particular worry centres on session expiration, even though I understand that sensitive information cannot be retrieved by the user from the server after the expiration. I look forward to your guidance on this matter. Thank you in advance.

hey @exkazuu you don't need to use SessionAuth. Instead, you can verify the JWT on SSR yourself using the getSession function (as shown here: https://supertokens.com/docs/thirdpartyemailpassword/nextjs/session-verification/in-ssr), and then use that info to render the page. For client side, instead of using SessionAuth, you can use the session context to check if a session exists, and also use

Session.validateClaims

(as shown in https://supertokens.com/docs/thirdpartyemailpassword/common-customizations/sessions/protecting-frontend-routes for custom UI) to verify the claims (this is essentially what session auth does)

I see, thanks!