https://supertokens.com/ logo
Join Discord
Powered by
Anyone having an idea where a `SessionError: INVA...
# support-questions-legacy
n
Anyone having an idea where a 
SessionError: INVALID_CLAIMS
is coming from - I get this after logging in with email + password. The stack trace is not that helpful
Copy code
SessionError: INVALID_CLAIMS
      at Session.<anonymous> (/app/node_modules/supertokens-node/lib/build/recipe/session/sessionClass.js:146:27)
      at Generator.next (<anonymous>)
      at fulfilled (/app/node_modules/supertokens-node/lib/build/recipe/session/sessionClass.js:15:36)
      at processTicksAndRejections (node:internal/process/task_queues:96:5) {
    type: 'INVALID_CLAIMS',
    payload: [ [Object] ],
    errMagic: 'ndskajfasndlfkj435234krjdsa',
    fromRecipe: 'session'
  }
On a site note - is there any plans for removing the async -> generator transform? Async functions are supported since a long time now and covered by all LTS versions https://node.green/#ES2017-features-async-functions
r
hey @n1ru4l can you print out the value of the 
payload
?
> On a site note - is there any plans for removing the async -> generator transform? Could you please open an issue about this on our github? We will have a look
n
let me see how i can print the payload - it is from staging logs 😄
r
thanks.
n
Is the payload safe to be JSON.stringified?
r
yes. It is
n
okay deploying soon -i will let you know
r
thanks
n
Copy code
[debug] SessionError [{"id":"st-ev","reason":{"message":"wrong value","expectedValue":true,"actualValue":false}}]
{"id":"st-ev","reason":{"message":"wrong value","expectedValue":true,"actualValue":false}}
is the payload
r
I see.
Have you initilaised email verification recipe on the backend but not on the frontend?
n
it should be initialised for sure, it happens in the code before
Copy code
const { backendConfig } = await import('@/config/supertokens/backend');
  const SupertokensNode = await import('supertokens-node');
  const Session = await import('supertokens-node/recipe/session');
  SupertokensNode.init(backendConfig());
  let session: SessionContainerInterface | undefined;

 
  try {
    console.log('[debug] before Session.getSession');
    session = await Session.getSession(context.req, context.res, { sessionRequired: false });
    console.log('[debug] after Session.getSession');
  } catch (e) {
    console.log('[debug] oh no it throws');
    if ('payload' in (e as any)) {
      console.log('[debug] SessionError', JSON.stringify((e as any).payload));
    }
    throw e;
  }
oh wait... I misread your question...
r
basically this is happening cause the user's email is not verified, and on the backend, you have done emailverification.init -> which essentially requires that the user's email is verified for session verification to succeed.
If you want to change that, either remove emailverification.init on the backend, or implement an email verification flow on the frontend, or set the emailverfiication on the backend to be in optional mode. Details of this can be found in our docs in the email verification section.
n
no it is required on both
ahhh i see
previously this was only verified on the frontend - i remember that i had a question related to this
r
yeaaa. So that changed in the new releases.
if you are using our pre built UI on the frontend, then post sign up, the frontend SDK should redirect you to the email verification page. If you are not using our pre built UI, you will have to make that flow.
n
okay so I kind of have to change my implementation to redirect to the verify email screen in that case
r
yes.
post sign up
n
we use the prebuilt ui
r
oh.. the pre built UI should redirect post sign up on its own
have you updated to the newer version of the frontend SDK?
n
i think we have some custom logic for redirecting to the latest visited url instead
r
Hmm. That's in the getRedirectionUrl function?
cause that function is only called after the email verification is done - in case email verification is required (which it is in this case)
n
trying to reproduce this issue locally now..
my first feedback thought: this error shouldn't be that cryptic
r
fair enough.
the payload was printed out as 
[ [Object] ]
which is why it was hard to decipher. But we can add some more info to it to make it easier
n
Copy code
"supertokens-auth-react": "0.27.1",
    "supertokens-node": "12.0.5",
    "supertokens-js-override": "0.0.4",
    "supertokens-website": "14.0.2",
so these are definetly the latest version 🤔 I guess the issue here is that we are doing the validation before anything happens on the frontend - within the server side props handler - thus - we should catch this case there and in that case redirect to the confirm email form?
r
Is the server side getSession running on all pages? Even the email verification page?
n
it runs on /
and after login i am kind of redirected there
or if i am already logged in and just visiting that page
so in any case i wanna catch this and redirect to the form i guess
we have some helper function:
Copy code
/**
 * Utility for protecting a server side props function with session handling.
 * Redirects user to the login page in case there is no session.
 */
export function withSessionProtection(handlerFn: GetServerSideProps = defaultHandler) {
  const getServerSideProps: GetServerSideProps = async context => {
    const result = await serverSidePropsSessionHandling(context);

    if (result) {
      return result;
    }

    return handlerFn(context);
  };

  return getServerSideProps;
}
r
Yea. You should do that.
it has the 
else if (err.type === Session.Error.UNAUTHORISED || err.type === Session.Error.INVALID_CLAIMS) {
line
so in case it's INVALID_CLAIMS, you can send a response to the frontend that indicates you need to redirect to the email verification page
n
i see - does 
err.type === Session.Error.INVALID_CLAIMS)
always mean email verification missing?
r
depends on the claims you have added.
For examlpe, the user roles adds its claims too
thats where the payload comes into the picture
n
and what was the url of the email page 😅
r
if the payload array contains an object with the 
id
st-ev
it's cause of email verification failure.
that being said, you should not have run into this issue at all - post sign in, the SDK should have redirected you to the email verification page
why is that not happening?
n
apparently it does not 😅 and i cannot see anything fishy tbh
r
hmm. That's really strange.
I'll investigate
n
it should be on the frontend config, right?
r
emailverification.init?
n
dont wanna let you search for sth that i might have broken in user code
😄
r
Yea, you need to add that to the frontend config's recipeList
n
Copy code
return {
    appInfo: appInfo(),
    recipeList: [
      ThirdPartyEmailPasswordReact.init({
        signInAndUpFeature: {
          providers,
        },
        override: env.auth.organizationOIDC ? getOIDCOverrides() : undefined,
      }),
      EmailVerification.init({
        mode: env.auth.requireEmailVerification ? 'REQUIRED' : 'OPTIONAL',
      }),
      SessionReact.init(),
    ],
  };
mode is definetly set to required
r
hmm.
let me check
Oh i think that's intentional from our side - my bad
We only do redirection post sign up
Or when is run on the frontend
but in your case the getServerSideProps runs before
n
yeah so the solution you proposed with the redirect makes sense
r
One simple solution to this would be to simply make the getSession function not check for claims at all in the getServerSideProps function
and then it will pass, and the SessionAuth on ther frontend will detect the failed claim and redirect on its own
n
I think the redirect approach is just fine tbh
r
Alright
n
it makes sense - the session is not valid unless the email is verified
r
but regardless (in case you change your mind), the way you can do the other thing is to call getSession like this:
Copy code
await Session.getSession(context.req, context.res, {
    overrideGlobalClaimValidators: () => {
        return []
    }
})
n
In that I case I think it is kind of more elegant to already start the redirect on the backend - compared to doing it on the frontend
Thanks again 🙂
r
fair enough 🙂
also keep in mind that this is an edge case - this situation will only happen if a user signed up and didn't do email verification and then tries to sign in again after
or if you change the config of email verification mode over time from REQUIRED to OPTIONAL and then back
4 Views
PreviousNext
Powered by