Hey @rp_st We want to integrate Supertokens into our Next js project. However, we are confused about getSSRToken. As seen in the screenshot, we expect the middleware to check the session and redirect it to the /auth path if the session does not exist. However, even if we log in to locahost:4001/auth/dashboard on the backend and delete the relevant user's session from the interface. getSSRToken returns us the session object as valid. How can we check whether the relevant session token is valid on the Next JS Server side?

hey @hasancanbuyukask3180 when you say "delete the relevant user's session from the interface", what do you mean? Deleting the session from the user management dashboard interface?

Yes @rp_st , we delete it via the user management dashboard.

right. So session verification is statless in supertokens. Which means that when you delete them offline, they will only get reflected in the user's browser when it tries and does a refresh (refresh api will fail). So to solve this, you have two options: - https://supertokens.com/docs/session/common-customizations/sessions/access-token-blacklisting - Or, implement your own caching method for keeping track of revoked sessions.

Hey @rp_st When I called get SSR as in the screenshot, it started returning undefined as it should be because there was no session. But now when the relevant logic works and NextResponse.redirect('http://localhost:4000/auth') is directed to the following path. Since the logic I showed with the arrow is True, it first goes back to Auth and then back to the path it came from. What needs to happen is to open the email password screen for me to log in again.

right. So, this happens cause the frontend state still indicates that a session exists, even though it doesn't

@rp_st However, as we talked about yesterday, you cannot use the JSX component in the middleware in Next JS.

hmm right.

did you revoke the session before calling this route?

I revoke it via User Dashboard. And in our Api project (written in Go), VerifySession is called before every request on the middleware side.

what is doint the redirect?

We don't have a special redirect, probably the TryRefreshComponent manages this redirect.

in case

hasToken

is false and

session

is undefined, you want to redirect to the

/auth

page

Correct! But as you said, for testing purposes, we directed you to a route where only the Try Refresh Component component was rendered.

and ofc, if you are redirecting to

/hasan

, you want to just render the component and not do a session check. So in the middleware, you have to make an exception for if the current path is

/hasan

, you don't do getSSRToken

There is a conflict here.

Which is?

I want to call the "getSSRToken" function in the "/auth" paths because I redirect to this path only if the conditions "!session !hasToken" are satisfied. Within the project, there are numerous pages, and I'm attempting to manage these operations through middleware to avoid adding the boilerplate code such as Try Refresh Component to each page individually.

why do you want to call getSSRToken in paths that start with /auth? Those are paths in which a session does not have to exist for them to work (for example the login page)

I think I solved the problem via middleware. Thanks for your support!

Oh okay! Can you share how?

I've updated the allowed routes, added a few checks during rendering, and resolved the issue. However, as a minor piece of feedback, your documentation for Next.js 13 is currently missing. I would like to offer support in updating those areas when I have the time.

That sounds great!!