Backend and frontend overrides (actions, hooks and UI customisation)
This section will guide you on overriding our default behaviour to achieve custom auth experiences. Specifically, we we will show you how to:
#
Features#
1) Override any UI / React component within the widgets that we provideThis will allow you to customize parts of the default UI without having to implement that whole UI widget from scratch
#
2) Override frontend functionsThis will allow you to change the way our widgets query the backend. Example use cases are:
- Sending analytics events based on user action.
- Custom caching logic if needed.
- Providing a custom router for routing that happens within our pre built UI. For example, integrating the NextJS router.
- Implementing your own session management system that works with our auth widgets.
#
3) Override backend functionsThis will allow you to change the behaviour of the functions that are used by the backend APIs exposed via our SDK. It can be useful for migration, using your own userID format, custom validation logic etc...
#
4) Override APIsThis will allow you to override the behaviour of any of the backend APIs our SDK exposes. It can be used for post / pre API callbacks or handling custom API input / output that deviate from our API specifications.
#
5) Frontend HooksThis allows you to change the request (body, headers, url etc) that is sent to your server, handle events fired by various user actions, and control how a recipe redirects a user. For example, you can use this to add an invite code to our sign up API call.
#
6) User ContextsThis allows you to pass information across recipe functions so that customisations can be made based on a specific "execution context".
#
Some example use casesUsing a combination of these, it should be possible to implement functionality that we don't provide out of the box:
- Adding reCAPTCHA to the login UI
- Using your own userID format
- Splitting sign in requests across SuperTokens and your database of existing users (useful for migration)
- Custom validation of emails for auth recipes in which we don't provide a config option for email validation.
- Changing the login form to first ask the user for their email, and show different methods for signing in based on their input (useful for migration)
- Implementing your own session management flow
- Adding post API callbacks
- Disabling sign up feature entirely
- Updating the online / offline status of a user post successful session verification
- And much more...