Open sasha240100 opened 5 months ago
Can you show how users can use one of the function props provided to SessionAuth? For example, overrideGlobalClaims function.
@rishabhpoddar In that case users will have to implement a ClientSessionAuth
in the middle between ServerSessionAuth
and SessionAuth
:
"use client";
import {PropsWithChildren} from 'react';
import {SessionAuth, SessionAuthProps} from 'supertokens-auth-react/recipe/session';
export function ClientSessionAuth(props: PropsWithChildren<SessionAuthProps>) {
// Custom implementation of overrideGlobalClaimValidators goes here
const overrideGlobalClaimValidators = () => []
return (
<SessionAuth {...props} overrideGlobalClaimValidators={overrideGlobalClaimValidators}>
{props.children}
</SessionAuth>
)
}
There are several things that prevent from having exactly the same function for overrideGlobalClaimValidators
on server side & client side:
SessionClaimValidator
on supertokens-node
and supertokens-auth-react
, they would have to be unified first, otherwise they will conflict.server components
cannot be executed on client side, the function that will be used on both server & client side has to be inside a client component
, which means that it cannot be passed as a prop to the ServerSessionAuth
component because it is a server component
.Types difference:
// supertokens-auth-react
export declare type SessionClaimValidator = {
readonly id: string;
/**
* Makes an API call that will refresh the claim in the token.
*/
refresh(userContext: any): Promise<void>;
/**
* Decides if we need to refresh the claim value before checking the payload with `validate`.
* E.g.: if the information in the payload is expired, or is not sufficient for this validator.
*/
shouldRefresh(accessTokenPayload: any, userContext: any): Promise<boolean> | boolean;
/**
* Decides if the claim is valid based on the accessTokenPayload object (and not checking DB or anything else)
*/
validate(accessTokenPayload: any, userContext: any): Promise<ClaimValidationResult> | ClaimValidationResult;
};
// supertokens-node
export declare type SessionClaimValidator = (
| // We split the type like this to express that either both claim and shouldRefetch is defined or neither.
{
claim: SessionClaim<any>;
/**
* Decides if we need to refetch the claim value before checking the payload with `isValid`.
* E.g.: if the information in the payload is expired, or is not sufficient for this check.
*/
shouldRefetch: (payload: any, userContext: any) => Promise<boolean> | boolean;
}
| {}
) & {
id: string;
/**
* Decides if the claim is valid based on the payload (and not checking DB or anything else)
*/
validate: (payload: any, userContext: any) => Promise<ClaimValidationResult>;
};
TODO for later (this is out of the scope of the interview trial): We need to do something about SuperTokensWrapper
as well.
TODOs:
Key takeaways about SSR support for SessionAuth
SessionAuth
needs to handle an initial context (initialSessionAuthContext
property from https://github.com/supertokens/supertokens-auth-react/pull/789).'use client';
or'use server';
depending on the components purpose.SessionAuth
does on both server & client. (see below)Example NextJS Server SessionAuth structure
Page
componentServerSessionAuth
component (server component) - an implementation of the SessionAuth logic on server side (retrieving session data from request, redirection and rendering logic)ClientSessionAuth
component [OPTIONAL] (client component) - needed in case you need to provide custom function properties likeonSessionExpired
oroverrideGlobalClaimValidators
SessionAuth
component (client component), fromsupertokens-auth-react
SessionAuth
component (client component), fromsupertokens-auth-react
Implementation
supertokens-auth-react
: https://github.com/supertokens/supertokens-auth-react/pull/789supertokens-node
: https://github.com/supertokens/supertokens-node/pull/785documentation
: (WIP)Example of ServerSessionAuth implementation (NextJS)
app/components/serverSessionAuth.tsx
:The logic in the above component is adapted for NextJS App Router, and depending on scenario other customisations to the
ServerSessionAuth
may be needed. Therefor, it is not a component forsupertokens-auth-react
library, and is rather a customer-side implementation that could be presented in documentation as example.