Add code block formatting

Author: bcbogdan

v2/package.json

@@ -4,7 +4,7 @@
   "private": true,
   "scripts": {
     "docusaurus": "docusaurus",
-    "start": "docusaurus start --host 0.0.0.0",
+    "start": "docusaurus start --host 0.0.0.0 --port 3002",
     "build": "./buildDocsForProduction",
     "build:ios": "MODE=production CODE_TYPE_CHECK=swift npx docusaurus build",
     "build-ignore-errors": "./buildDocsForProduction true",
@@ -48,4 +48,5 @@
     "@types/react": "^16.14.11",
     "typescript": "4.9.3"
   }
-}
+}
+

v3/docs/additional-verification/mfa/backend-setup.mdx

@@ -142,7 +142,7 @@ Account linking is a paid feature, and you need to generate a license key to ena
 
 We start by initialising the MFA recipe on the backend and specifying the list of first factors using their [factor IDs](./important-concepts#auth-factor-ids). You still have to initialise all the auth recipes in the `recipeList`, and configure them based on your needs. 
 
-For example, the code below initializes `thirdparty`, `emailpassword` and `passwordless` recipes and sets the `firstFactor` array to be `["emailpassword", "thirdparty"]`. This means that we will show email password and social login to the user as the first factor (using the `thirdparty` + `emailpassword` recipe), and use `passwordless` for the second factor.
+For example, the code below inits `thirdparty`, `emailpassword` and `passwordless` recipes and sets the `firstFactor` array to be `["emailpassword", "thirdparty"]`. This means that we will show email password and social login to the user as the first factor (using the `thirdparty` + `emailpassword` recipe), and use `passwordless` for the second factor.
 
 <BackendTabs>
 <BackendTabs.TabItem value="nodejs">
@@ -230,7 +230,7 @@ There are of course other combinations of first factors that you may want to add
 
 ### Multi tenant setup
 
-For a multi tenancy setup, where each tenant can have a different set of first factors, you can leave the `firstFactors` array as `undefined` in the `MultiFactorAuth.init` and configure the `firstFactors` on a per tenant basis when you are creating / updating a tenant as shown below:
+For a multi tenancy setup, where each tenant can have a different set of first factors, you can leave the `firstFactors` array as `undefined` in the `MultiFactorAuth.init` and configure the firstFactors on a per tenant basis when you are creating / updating a tenant as shown below:
 
 <BackendTabs additionalValues={[{label: "Curl", value: "curl"}, {label: "Dashboard", value: "dashboard"}]}>
 
@@ -257,7 +257,7 @@ We have set `firstFactors` only to include `"emailpassword"`. This means that us
 
 :::important
 - If you do not configure `firstFactors` array on a tenant config, then no factors will be enabled for that tenant by default.
-- To remove the `firstFactors` configuration for a tenant, you can simply pass a `null` value for the `firstFactors` key in the tenant config. For that tenant, this will make SuperTokens default to the `firstFactors` array in the `MultiFactorAuth.init` from the backend `init` config.
+- To remove the `firstFactors` configuation for a tenant, you can simply pass a `null` value for the `firstFactors` key in the tenant config. For that tenant, this will make SuperTokens default to the `firstFactors` array in the `MultiFactorAuth.init` from the backend's `init` config.
 :::
 
 </BackendTabs.TabItem>
@@ -335,7 +335,7 @@ We have set `firstFactors` only to include `"emailpassword"`. This means that us
 
 :::important
 - If you do not configure `firstFactors` array on a tenant config, then no factors will be enabled for that tenant by default.
-- To remove the `firstFactors` configuration for a tenant, you can simply pass a `null` value for the `firstFactors` key in the tenant config. For that tenant, this will make SuperTokens default to the `firstFactors` array in the `MultiFactorAuth.init` from the backend `init` config.
+- To remove the `firstFactors` configuation for a tenant, you can simply pass a `null` value for the `firstFactors` key in the tenant config. For that tenant, this will make SuperTokens default to the `firstFactors` array in the `MultiFactorAuth.init` from the backend's `init` config.
 :::
 
 </BackendTabs.TabItem>
@@ -492,7 +492,7 @@ init(
 </BackendTabs.TabItem>
 </BackendTabs>
 
-In the above snippet, we have configured email password and social login as the first factor, followed by TOTP as the second factor.
+In the above snippet, we have configured email password and social login as the first factor, followed by totp as the second factor.
 
 After sign in or sign up, SuperTokens calls the `getMFARequirementsForAuth` function to get a list of secondary factors for the user. The returned value is used to determine the boolean value of `v` that's stored in the session's access token payload. If the returned factor is already completed (it's in the `c` object of the session's payload), then the value of `v` will be `true`, else `false`.
 
@@ -1103,7 +1103,7 @@ Notice that the input to the function contains the `requiredSecondaryFactorsForT
 
 Instead of configuring a factor for all users in your app, or for all users within a tenant, you may want to implement a flow in which users do MFA only if they have enabled it for themselves. Here, users may also want to choose what factors they would like to enable for themselves.
 
-This flow is usually achieved by allowing users to configure their MFA preferences in the settings page in your app's frontend. We don't yet provide a pre-built UI for this, but in this section, we will talk about how to setup this up on the backend.
+This flow is usually achieved by allowing users to configure their MFA preferences in the settings page in your app's frontend. We don't yet provide a pre built UI for this, but in this section, we will talk about how to setup this up on the backend.
 
 You want to start by creating an API that does [session verification](/docs/additional-verification/session-verification/protect-api-routes/overview), and then enable the desired factor for the user. For example, if the user wants to enable TOTP, then you would call the following function in your API:
 
@@ -1269,7 +1269,7 @@ init(
 </BackendTabs.TabItem>
 </BackendTabs>
 
-Once you call the `addToRequiredSecondaryFactorsForUser` function for a user, SuperTokens will save this preference in the user metadata JSON of the user. For example, if you add `"totp"` as a required secondary factor for a user, this will be saved in the metadata JSON as:
+Once you call the `addToRequiredSecondaryFactorsForUser` function for a user, SuperTokens will save this preference in the usermetadata JSON of the user. For example, if you add `"totp"` as a required secondary factor for a user, this will be saved in the metadata JSON as:
 
 ```json
 {
@@ -1399,14 +1399,14 @@ def is_totp_enabled_for_user(user_id: str):
 </BackendTabs.TabItem>
 </BackendTabs>
 
-Or you can call the [`MFAInfo` endpoint](./frontend-setup#mfa-info-endpoint) from the frontend which returns information indicating which factors have already been setup for the user and which not.
+Or you can call the [MFAInfo endpoint](./frontend-setup#mfa-info-endpoint) from the frontend which returns information indicating which factors have already been setup for the user and which not.
 
 A factor is considered setup if the user has gone through that factor's flow at least once. For example, if the user has created and verified a TOTP device, only then will the `getFactorsSetupForUser` function return `totp` as part of the array. Likewise, if the user has completed `otp-email` or `link-email` once, only then will these factors be a part of the returned array. Let's take two examples:
-- The first time the user enables TOTP, then the result of `getFactorsSetupForUser` will not contain `"totp"`. So you should redirect the user to the TOTP setup screen. Once they add and verify a device, then `getFactorsSetupForUser` will return `["totp"]` even if they later disable TOTP from the settings page and re-enable it.
+- The first time the user enables TOTP, then the result of `getFactorsSetupForUser` will not contain `"totp"`. So you should redirect the user to the totp setup screen. Once they add and verify a device, then `getFactorsSetupForUser` will return `["totp"]` even if they later disable totp from the settings page and re-enable it.
 - Let's say that the first factor for a user is `emailpassword`, and the second factor is `otp-email`. Once they sign up, SuperTokens already knows the email for the user, so when they are doing the `otp-email` step, then they will not be asked to enter their email again (i.e. an OTP will be sent to them directly). However, until they actually complete the OTP flow, `getFactorsSetupForUser` will not return `["otp-email"]` as part of the output.
 
 :::caution
-In the edge case that the a factor is enabled for a user, but they sign out before setting it up, then when they login next, SuperTokens will still ask them to complete the factor at that time. If SuperTokens doesn't have the required information (like no TOTP device for TOTP auth), then users will be asked to setup a device at that point in time.
+In the edge case that the a factor is enabled for a user, but they sign out before setting it up, then when they login next, SuperTokens will still ask them to complete the factor at that time. If SuperTokens doesn't have the required information (like no TOTP device for totp auth), then users will be asked to setup a device at that point in time.
 
 If you would like to change how this works and only want users to setup their factor via the settings page, and not during sign in, you can do so by overriding the `getMFARequirementsForAuth` function, which takes as an input the list of factors that are setup for the current user.
 :::