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.

Recipe selection for pre-built UI

Status

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

Status:
proposed
Deciders:
rishabhpoddar, sattvikc
Proposed by:
sattvikc
Created:
2022-12-08

Context and Problem Statement#

In case of usesDynamicLoginMethods set to true, the backend responds with the recipes that are enabled in the core for a particular tenant, such as:

{  "thirdParty": {    "enabled": true/false,    ...  },  "emailpassword": {    "enabled": true/false,    ...  },  "passwordless": {    "enabled": true/false,    ...  }}

Along with this, the user would have statically initialized a combination of auth recipes, such as emailpassword & thirdpartypasswordless, etc.

Based on the information provided by backend (core) and the recipies initialized by the user, the SDK needs to decide which recipes must be used for the UI

Considered Options#

  • Automatically create a recipe combination based on the recipies enabled in the core if not statically declared
  • Use the recipeList created by the user and run a priority algorithm on it to pick the right one to enable

Automatically create a recipe combination based on the recipies enabled in the core if not statically declared#

In this approach, if the user has not statically initialized a matching recipe, the SDK will automatically create a recipe combination based on the recipies enabled in the core. This also implies that we would get rid of thirdpartyemailpassword and thirdpartypasswordless and instead build the UI in a way that would allow for any combination of emailpassword, thirdparty and passwordless recipes used together.

  • Best user experience
  • When `usesDynamicLoginMethods` is enabled, auth recipe inits won't be required by the user
  • Time consuming to implement for us given how our SDKs work at the moment
  • Decision Outcome#

    Chosen outcome: Use the recipeList created by the user and run a priority algorithm on it to pick the right one to enable

    Step 1 Find an exact match (more examples later)#

    The SDK will first try to find if there is an exact match between the recipies initialized in the frontend and the recipies enabled in the core.

    For example, if thidparty and emailpassword is enabled in the core and the user has initialized thirdpartyemailpassword recipe on the frontend, that will be used.

    Step 2 Find a partial match (more examples later)#

    If the Step 1 has failed, the SDK will try to find and pick matching recipes and then use that for the UI, in the following priority order:

    • thirdpartyemailpassword
    • thirdpartypasswordless
    • emailpassword
    • passwordless
    • thirdparty

    For example, if thirdparty and emailpassword is enabled in the core and the user has initialized emailpassword & thirdpartypasswordless recipe on the frontend, thirdpartypasswordless with passwordless disabled and emailpassword would be picked, based on the priority order.

    Note if all recipes can't be matched, the SDK will NOT throw error, instead it will use the partially matched recipes to present the UI. This is because if we think of the base case, where the core has defaultTenantId with all recipes enabled, but the user has only initialised the emailpassword recipe (with usesDynamicLoginMethods: true), then we still want the app to work and not throw an error. If we do not do this, then the user will have to also change the defaultTenantId setting in the core to disable thirdparty and passwordless, or not use the usesDynamicLoginMethods: true config.

    Step 3#

    If the Step 2 also fails, the SDK will throw an error, as there is no match at all.

    For example, if thirdparty and emailpassword is enabled in the core and the user has initialized passwordless recipe on the frontend, it will result in an error.

    Pros and Cons#

  • Presents best matched UI
  • The logic is complicated and difficult to communicate to user
  • Examples and results#

    Recipes Enabled in CoreRecipes initialized on frontendSelected Recipe for UI
    emailpasswordemailpasswordemailpassword
    thirdpartythirdpartyemailpasswordthirdpartyemailpassword with emailpassword disabled
    thirdparty & emailpasswordthirdpartyemailpasswordthirdpartyemailpassword
    thirdparty & emailpasswordthirdparty & emailpasswordthirdparty & emailpassword
    thirdparty & emailpasswordthirdparty & passwordlessthirdparty
    thirdparty & emailpasswordemailpassword & thirdpartyemailpasswordthirdpartyemailpassword
    thirdparty & emailpasswordemailpassword & thirdpartypasswordlessthirdpartypasswordless with passwordless disabled & emailpassword
    thirdparty & emailpassword & passwordlessthirdpartyemailpassword & thirdpartypasswordlessthirdpartyemailpassword & thirdpartypasswordless with thirdparty disabled