diff --git a/v2/emailpassword/common-customizations/sessions/claims/claim-validators.mdx b/v2/emailpassword/common-customizations/sessions/claims/claim-validators.mdx
index 12eeee0c0..8900a22f7 100644
--- a/v2/emailpassword/common-customizations/sessions/claims/claim-validators.mdx
+++ b/v2/emailpassword/common-customizations/sessions/claims/claim-validators.mdx
@@ -267,7 +267,25 @@ type ClaimValidationResult = { isValid: true } | { isValid: false; reason?: any
- The `refresh` function is the same as the one in the frontend claim interface.
-- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`.
+- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`. When implementing this function for a `SessionClaimValidator` and using `Date.now`, it's advisable to use `DateProvider.now` from our SDK. This mitigates potential clock skew issues by accounting for the time difference between the frontend and backend. Use `DateProvider` as shown:
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-auth-react/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-web-js/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
- The `validate` function checks the `accessTokenPayload` for the value of the claim and returns an appropriate response.
diff --git a/v2/passwordless/common-customizations/sessions/claims/claim-validators.mdx b/v2/passwordless/common-customizations/sessions/claims/claim-validators.mdx
index 12eeee0c0..8900a22f7 100644
--- a/v2/passwordless/common-customizations/sessions/claims/claim-validators.mdx
+++ b/v2/passwordless/common-customizations/sessions/claims/claim-validators.mdx
@@ -267,7 +267,25 @@ type ClaimValidationResult = { isValid: true } | { isValid: false; reason?: any
- The `refresh` function is the same as the one in the frontend claim interface.
-- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`.
+- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`. When implementing this function for a `SessionClaimValidator` and using `Date.now`, it's advisable to use `DateProvider.now` from our SDK. This mitigates potential clock skew issues by accounting for the time difference between the frontend and backend. Use `DateProvider` as shown:
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-auth-react/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-web-js/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
- The `validate` function checks the `accessTokenPayload` for the value of the claim and returns an appropriate response.
diff --git a/v2/session/common-customizations/sessions/claims/claim-validators.mdx b/v2/session/common-customizations/sessions/claims/claim-validators.mdx
index 12eeee0c0..8900a22f7 100644
--- a/v2/session/common-customizations/sessions/claims/claim-validators.mdx
+++ b/v2/session/common-customizations/sessions/claims/claim-validators.mdx
@@ -267,7 +267,25 @@ type ClaimValidationResult = { isValid: true } | { isValid: false; reason?: any
- The `refresh` function is the same as the one in the frontend claim interface.
-- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`.
+- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`. When implementing this function for a `SessionClaimValidator` and using `Date.now`, it's advisable to use `DateProvider.now` from our SDK. This mitigates potential clock skew issues by accounting for the time difference between the frontend and backend. Use `DateProvider` as shown:
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-auth-react/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-web-js/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
- The `validate` function checks the `accessTokenPayload` for the value of the claim and returns an appropriate response.
diff --git a/v2/src/plugins/codeTypeChecking/jsEnv/package.json b/v2/src/plugins/codeTypeChecking/jsEnv/package.json
index 53cadb10b..8fb27cc14 100644
--- a/v2/src/plugins/codeTypeChecking/jsEnv/package.json
+++ b/v2/src/plugins/codeTypeChecking/jsEnv/package.json
@@ -55,14 +55,14 @@
"react-router-dom5": "npm:react-router-dom@^5.3.0",
"socket.io": "^4.6.1",
"socketio": "^1.0.0",
- "supertokens-auth-react": "^0.36.0",
+ "supertokens-auth-react": "^0.37.0",
"supertokens-node": "^16.7.0",
"supertokens-node7": "npm:supertokens-node@7.3",
"supertokens-react-native": "^4.0.0",
- "supertokens-web-js": "^0.8.0",
- "supertokens-web-js-script": "github:supertokens/supertokens-web-js#0.8",
- "supertokens-website": "^17.0.0",
- "supertokens-website-script": "github:supertokens/supertokens-website#17.0",
+ "supertokens-web-js": "^0.9.0",
+ "supertokens-web-js-script": "github:supertokens/supertokens-web-js#0.9",
+ "supertokens-website": "^18.0.0",
+ "supertokens-website-script": "github:supertokens/supertokens-website#18.0",
"typescript": "^4.9.5"
}
}
diff --git a/v2/thirdparty/common-customizations/sessions/claims/claim-validators.mdx b/v2/thirdparty/common-customizations/sessions/claims/claim-validators.mdx
index 12eeee0c0..8900a22f7 100644
--- a/v2/thirdparty/common-customizations/sessions/claims/claim-validators.mdx
+++ b/v2/thirdparty/common-customizations/sessions/claims/claim-validators.mdx
@@ -267,7 +267,25 @@ type ClaimValidationResult = { isValid: true } | { isValid: false; reason?: any
- The `refresh` function is the same as the one in the frontend claim interface.
-- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`.
+- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`. When implementing this function for a `SessionClaimValidator` and using `Date.now`, it's advisable to use `DateProvider.now` from our SDK. This mitigates potential clock skew issues by accounting for the time difference between the frontend and backend. Use `DateProvider` as shown:
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-auth-react/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-web-js/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
- The `validate` function checks the `accessTokenPayload` for the value of the claim and returns an appropriate response.
diff --git a/v2/thirdpartyemailpassword/common-customizations/sessions/claims/claim-validators.mdx b/v2/thirdpartyemailpassword/common-customizations/sessions/claims/claim-validators.mdx
index 12eeee0c0..8900a22f7 100644
--- a/v2/thirdpartyemailpassword/common-customizations/sessions/claims/claim-validators.mdx
+++ b/v2/thirdpartyemailpassword/common-customizations/sessions/claims/claim-validators.mdx
@@ -267,7 +267,25 @@ type ClaimValidationResult = { isValid: true } | { isValid: false; reason?: any
- The `refresh` function is the same as the one in the frontend claim interface.
-- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`.
+- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`. When implementing this function for a `SessionClaimValidator` and using `Date.now`, it's advisable to use `DateProvider.now` from our SDK. This mitigates potential clock skew issues by accounting for the time difference between the frontend and backend. Use `DateProvider` as shown:
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-auth-react/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-web-js/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
- The `validate` function checks the `accessTokenPayload` for the value of the claim and returns an appropriate response.
diff --git a/v2/thirdpartypasswordless/common-customizations/sessions/claims/claim-validators.mdx b/v2/thirdpartypasswordless/common-customizations/sessions/claims/claim-validators.mdx
index 12eeee0c0..8900a22f7 100644
--- a/v2/thirdpartypasswordless/common-customizations/sessions/claims/claim-validators.mdx
+++ b/v2/thirdpartypasswordless/common-customizations/sessions/claims/claim-validators.mdx
@@ -267,7 +267,25 @@ type ClaimValidationResult = { isValid: true } | { isValid: false; reason?: any
- The `refresh` function is the same as the one in the frontend claim interface.
-- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`.
+- `shouldRefresh` is function which determines if the claim should be checked against the backend before calling `validate`. This usually returns `true` if the claim value is too old or if it is not present in the `accessTokenPayload`. When implementing this function for a `SessionClaimValidator` and using `Date.now`, it's advisable to use `DateProvider.now` from our SDK. This mitigates potential clock skew issues by accounting for the time difference between the frontend and backend. Use `DateProvider` as shown:
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-auth-react/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
+
+
+
+```tsx
+import { DateProviderReference } from "supertokens-web-js/utils/dateProvider";
+DateProviderReference.getReferenceOrThrow().dateProvider.now();
+```
+
+
- The `validate` function checks the `accessTokenPayload` for the value of the claim and returns an appropriate response.