From 3aa9f54c0739207e87c9981a7f9f39b2258c4f8e Mon Sep 17 00:00:00 2001 From: rishabhpoddar Date: Wed, 6 Dec 2023 20:01:03 +0530 Subject: [PATCH] fixes typo --- v2/emailpassword/common-customizations/multiple-clients.mdx | 2 +- v2/passwordless/common-customizations/multiple-clients.mdx | 2 +- v2/thirdparty/common-customizations/multiple-clients.mdx | 2 +- .../common-customizations/multiple-clients.mdx | 2 +- .../common-customizations/multiple-clients.mdx | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/v2/emailpassword/common-customizations/multiple-clients.mdx b/v2/emailpassword/common-customizations/multiple-clients.mdx index ba7a5d182..09f699b2c 100644 --- a/v2/emailpassword/common-customizations/multiple-clients.mdx +++ b/v2/emailpassword/common-customizations/multiple-clients.mdx @@ -16,7 +16,7 @@ Many a times, you have a setup where different frontend clients query the same b In all these cases, the location of the different frontend clients are different. In case of a mobile app, it can be a deep link to the app, in case of local development, it can be `http://localhost:3000`, for staging, it can be `https://test.yoursite.com`, etc. Not only is the domain different, but so is the protocol (http vs https). -All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http:localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`. +All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http://localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`. ## Step 1: Define a dynamic origin on the backend diff --git a/v2/passwordless/common-customizations/multiple-clients.mdx b/v2/passwordless/common-customizations/multiple-clients.mdx index ba7a5d182..09f699b2c 100644 --- a/v2/passwordless/common-customizations/multiple-clients.mdx +++ b/v2/passwordless/common-customizations/multiple-clients.mdx @@ -16,7 +16,7 @@ Many a times, you have a setup where different frontend clients query the same b In all these cases, the location of the different frontend clients are different. In case of a mobile app, it can be a deep link to the app, in case of local development, it can be `http://localhost:3000`, for staging, it can be `https://test.yoursite.com`, etc. Not only is the domain different, but so is the protocol (http vs https). -All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http:localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`. +All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http://localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`. ## Step 1: Define a dynamic origin on the backend diff --git a/v2/thirdparty/common-customizations/multiple-clients.mdx b/v2/thirdparty/common-customizations/multiple-clients.mdx index ba7a5d182..09f699b2c 100644 --- a/v2/thirdparty/common-customizations/multiple-clients.mdx +++ b/v2/thirdparty/common-customizations/multiple-clients.mdx @@ -16,7 +16,7 @@ Many a times, you have a setup where different frontend clients query the same b In all these cases, the location of the different frontend clients are different. In case of a mobile app, it can be a deep link to the app, in case of local development, it can be `http://localhost:3000`, for staging, it can be `https://test.yoursite.com`, etc. Not only is the domain different, but so is the protocol (http vs https). -All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http:localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`. +All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http://localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`. ## Step 1: Define a dynamic origin on the backend diff --git a/v2/thirdpartyemailpassword/common-customizations/multiple-clients.mdx b/v2/thirdpartyemailpassword/common-customizations/multiple-clients.mdx index 23bbc6369..85caa184e 100644 --- a/v2/thirdpartyemailpassword/common-customizations/multiple-clients.mdx +++ b/v2/thirdpartyemailpassword/common-customizations/multiple-clients.mdx @@ -16,7 +16,7 @@ Many a times, you have a setup where different frontend clients query the same b In all these cases, the location of the different frontend clients are different. In case of a mobile app, it can be a deep link to the app, in case of local development, it can be `http://localhost:3000`, for staging, it can be `https://test.yoursite.com`, etc. Not only is the domain different, but so is the protocol (http vs https). -All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http:localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`. +All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http://localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`. ## Step 1: Define a dynamic origin on the backend diff --git a/v2/thirdpartypasswordless/common-customizations/multiple-clients.mdx b/v2/thirdpartypasswordless/common-customizations/multiple-clients.mdx index ba7a5d182..09f699b2c 100644 --- a/v2/thirdpartypasswordless/common-customizations/multiple-clients.mdx +++ b/v2/thirdpartypasswordless/common-customizations/multiple-clients.mdx @@ -16,7 +16,7 @@ Many a times, you have a setup where different frontend clients query the same b In all these cases, the location of the different frontend clients are different. In case of a mobile app, it can be a deep link to the app, in case of local development, it can be `http://localhost:3000`, for staging, it can be `https://test.yoursite.com`, etc. Not only is the domain different, but so is the protocol (http vs https). -All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http:localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`. +All of these have an impact on the functioning of SuperTokens. For example, if your frontend is on `localhost` and your API is `api.example.com`, then the `cookieSameSite` value for sessions should resolve to `none`, whereas if the frontend is on `test.example.com`, then the `cookieSameSite` value should resolve to `lax`. Another example is the effect on magic links, password reset or email verification links - the domains and protocols of these would need to change based on the frontend that is querying - if the query is coming from the `localhost` site, then the link URL would be `http://localhost...`, whereas if it's coming from the test site, it would be `https://test.example.com...`. ## Step 1: Define a dynamic origin on the backend