StaticErrorStaticinitStaticcreateJWTOptionalpayload: anyOptionalvaliditySeconds: numberOptionaluseStaticSigningKey: booleanOptionaluserContext: Record<string, any>StaticcreateOptionaluserContext: Record<string, any>StaticcreateOptionaluserContext: Record<string, any>StaticfetchStaticgetOptionaltenantId: stringOptionaluserContext: Record<string, any>StaticgetStaticgetJWKSOptionaluserContext: Record<string, any>StaticgetOptionaluserContext: Record<string, any>StaticgetOptionaloptions: VerifySessionOptions & { sessionRequired?: true }OptionaluserContext: Record<string, any>Optionaloptions: VerifySessionOptions & { sessionRequired: false }OptionaluserContext: Record<string, any>Optionaloptions: VerifySessionOptionsOptionaluserContext: Record<string, any>StaticgetOptionaluserContext: Record<string, any>StaticgetThe access token extracted from the authorization header or cookies
OptionalantiCsrfToken: stringThe anti-csrf token extracted from the authorization header or cookies. Can be undefined if antiCsrfCheck is false
Tries to validate an access token and build a Session object from it.
Notes about anti-csrf checking:
antiCsrf is set to VIA_HEADER in the Session recipe config you have to handle anti-csrf checking before calling this function and set antiCsrfCheck to false in the options.Results: OK: The session was successfully validated, including claim validation CLAIM_VALIDATION_ERROR: While the access token is valid, one or more claim validators have failed. Our frontend SDKs expect a 403 response the contents matching the value returned from this function. TRY_REFRESH_TOKEN_ERROR: This means, that the access token structure was valid, but it didn't pass validation for some reason and the user should call the refresh API. You can send a 401 response to trigger this behaviour if you are using our frontend SDKs UNAUTHORISED: This means that the access token likely doesn't belong to a SuperTokens session. If this is unexpected, it's best handled by sending a 401 response.
The access token extracted from the authorization header or cookies
OptionalantiCsrfToken: stringThe anti-csrf token extracted from the authorization header or cookies. Can be undefined if antiCsrfCheck is false
Optionaloptions: VerifySessionOptions & { sessionRequired?: true }Same options objects as getSession or verifySession takes, except the sessionRequired prop, which is always set to true in this function
OptionaluserContext: Record<string, any>User context
Tries to validate an access token and build a Session object from it.
Notes about anti-csrf checking:
antiCsrf is set to VIA_HEADER in the Session recipe config you have to handle anti-csrf checking before calling this function and set antiCsrfCheck to false in the options.Results: OK: The session was successfully validated, including claim validation CLAIM_VALIDATION_ERROR: While the access token is valid, one or more claim validators have failed. Our frontend SDKs expect a 403 response the contents matching the value returned from this function. TRY_REFRESH_TOKEN_ERROR: This means, that the access token structure was valid, but it didn't pass validation for some reason and the user should call the refresh API. You can send a 401 response to trigger this behaviour if you are using our frontend SDKs UNAUTHORISED: This means that the access token likely doesn't belong to a SuperTokens session. If this is unexpected, it's best handled by sending a 401 response.
The access token extracted from the authorization header or cookies
OptionalantiCsrfToken: stringThe anti-csrf token extracted from the authorization header or cookies. Can be undefined if antiCsrfCheck is false
Optionaloptions: VerifySessionOptions & { sessionRequired: false }Same options objects as getSession or verifySession takes, except the sessionRequired prop, which is always set to true in this function
OptionaluserContext: Record<string, any>User context
Tries to validate an access token and build a Session object from it.
Notes about anti-csrf checking:
antiCsrf is set to VIA_HEADER in the Session recipe config you have to handle anti-csrf checking before calling this function and set antiCsrfCheck to false in the options.Results: OK: The session was successfully validated, including claim validation CLAIM_VALIDATION_ERROR: While the access token is valid, one or more claim validators have failed. Our frontend SDKs expect a 403 response the contents matching the value returned from this function. TRY_REFRESH_TOKEN_ERROR: This means, that the access token structure was valid, but it didn't pass validation for some reason and the user should call the refresh API. You can send a 401 response to trigger this behaviour if you are using our frontend SDKs UNAUTHORISED: This means that the access token likely doesn't belong to a SuperTokens session. If this is unexpected, it's best handled by sending a 401 response.
The access token extracted from the authorization header or cookies
OptionalantiCsrfToken: stringThe anti-csrf token extracted from the authorization header or cookies. Can be undefined if antiCsrfCheck is false
Optionaloptions: VerifySessionOptionsSame options objects as getSession or verifySession takes, except the sessionRequired prop, which is always set to true in this function
OptionaluserContext: Record<string, any>User context
StaticmergeOptionaluserContext: Record<string, any>StaticrefreshOptionaluserContext: Record<string, any>StaticrefreshOptionalantiCsrfToken: stringOptionaluserContext: Record<string, any>StaticremoveStaticrevokeOptionaltenantId: stringOptionaluserContext: Record<string, any>StaticrevokeStaticrevokeOptionaluserContext: Record<string, any>StaticsetStaticupdateStaticvalidateOptionaloverrideGlobalClaimValidators: (OptionaluserContext: Record<string, any>
Tries to validate an access token and build a Session object from it.
Notes about anti-csrf checking:
antiCsrfis set to VIA_HEADER in the Session recipe config you have to handle anti-csrf checking before calling this function and set antiCsrfCheck to false in the options.Results: OK: The session was successfully validated, including claim validation CLAIM_VALIDATION_ERROR: While the access token is valid, one or more claim validators have failed. Our frontend SDKs expect a 403 response the contents matching the value returned from this function. TRY_REFRESH_TOKEN_ERROR: This means, that the access token structure was valid, but it didn't pass validation for some reason and the user should call the refresh API. You can send a 401 response to trigger this behaviour if you are using our frontend SDKs UNAUTHORISED: This means that the access token likely doesn't belong to a SuperTokens session. If this is unexpected, it's best handled by sending a 401 response.