Skip to main content
important

This is a contributors guide and NOT a user guide. Please visit these docs if you are using or evaluating SuperTokens.

Add a new versions of createNew/refresh/getSession without response

Status

This is just a proposal so far, it hasn't been accepted and needs further discussion.

Status:
proposed
Deciders:
rishabhpoddar, porcellus
Proposed by:
porcellus
Created:
2022-12-13
Last updated:
2023-01-02

Context and Problem Statement#

In some cases, the BE may need to create, refresh or validate access tokens based on the token strings only, with no access to the request/response objects.

Considered Options#

  • Recommend using a jwt verification lib
  • Add a new functions that take/return the tokens as a strings
  • Ask user to mock the req / res object passed to getSession and read tokens from that

Decision Outcome#

We've decided to add new functions: getSessionWithoutModifyingResponse, refreshSessionWithoutModifyingResponse, createNewSessionWithoutModifyingResponse functions that take/return the tokens as a string:

  • This will be very similar to the existing functions
  • It will need to add a new session container type that makes it explicit that you can't update the session on the FE through it.
  • It should not throw, match the pattern of { status: "OK", session: ImmutableSessionContainer }

ImmutableSessionContainer should:

  • Provide no modifying functions. (a deprecated&throwing version would mean we move this error to the runtime)
  • Have the same "read" functions: getUserId, getSessionHandle, etc.

Recommend using a jwt verification lib#

  • No implementation effort
  • No access to claim validators
  • Can't check blacklist
  • Recommends not using our SDK
  • Add a new functions that take/return the tokens as a strings#

  • Provides access to validators
  • Can return nicely typed object that disallows modification of the session
  • A new functions in the interface
  • Ask user to mock the req / res object passed to getSession and read tokens from that#

  • Provides access to validators
  • The same docs could help people add their own/new frameworks
  • A lot more documentation
  • It could require more effort from the user than this use-case should
  • Asking people to add an implementation things like `getHeader` that doesn't actually read headers feels very hacky
  • We could still add this type of documentation while handling the more common use-cases by adding specific functions