Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughRewrites React SDK v5 docs: replaces migration-first flow with prescriptive setup, expands and clarifies public API (new methods, hooks, components), adds portal and access-control flows, and updates token/claims and refresh guidance alongside many examples and editorial fixes. (50 words) Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying kinde-docs-preview with
|
| Latest commit: |
7fee8b6
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://592dd9f4.kinde-docs-preview.pages.dev |
| Branch Preview URL: | https://tamal-update-react-sdk-page.kinde-docs-preview.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx`:
- Around line 1449-1456: The getPermission output example is inconsistent: the
earlier example for getPermission includes permissionKey but the later one only
shows orgCode and isGranted; update the later output example for getPermission
to include the permissionKey field (e.g., permissionKey: "read:todos") so both
examples match, ensuring the JSON shown for getPermission contains
{permissionKey: "...", orgCode: "org_1234", isGranted: true}.
- Line 111: Remove the stray leading space in the PackageManagers usage so the
pkg prop value is the exact package name; locate the PackageManagers component
instance where pkg=" `@kinde-oss/kinde-auth-react`" and change it to
pkg="@kinde-oss/kinde-auth-react" to avoid copying an invalid install string.
🧹 Nitpick comments (1)
src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx (1)
1022-1029: Consider adding optional chaining for consistency.This example accesses
user.givenName,user.familyName, etc. without optional chaining, while earlier examples (lines 280-281, 305-306) useuser?.givenName. For consistency and to prevent potential runtime errors whenuseris null/undefined, consider using optional chaining here as well.Suggested fix
return ( <div> - <h1>{user.givenName} {user.familyName}</h1> - <p>{user.email}</p> - <img src={user.picture} alt="User profile" /> + <h1>{user?.givenName} {user?.familyName}</h1> + <p>{user?.email}</p> + <img src={user?.picture} alt="User profile" /> </div> )
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx`:
- Around line 1244-1249: The JSON example showing authentication tokens has a
missing comma after the idToken property which makes the object invalid; edit
the example in react-sdk.mdx (the token response example block containing
success, accessToken, idToken, refreshToken) and insert a comma immediately
after the idToken value so the object literal is syntactically correct.
- Around line 1442-1455: Update the example output so it matches the requested
permission in the code sample: change the displayed permissionKey from
"create:todos" to "read:todos" in the output block associated with
runAsyncFunction/getPermission, ensuring the example output reflects
permissionKey: "read:todos" (and keep orgCode and isGranted unchanged).
- Around line 1063-1068: Doc currently mixes redirect parameter names across the
provider and methods; add a short clarifying note near the parameter list
stating that the provider prop is KindeProvider's redirectUri (used as the
default redirect), while individual auth methods (login(), register(), logout())
accept method-specific options that can override it — login()/register() expect
redirectURL per `@kinde/js-utils` LoginMethodParams and logout() may use
redirectUrl — mention these exact symbols (KindeProvider.redirectUri, login(),
register(), logout(), redirectURL, redirectUrl, LoginMethodParams) so readers
know which name to use where.
- Around line 1069-1071: Update the API docs so the `state` parameter is typed
and described as an `object` (not `string`) — change the entry for `state` to
indicate it accepts an object used to persist application state (e.g., `{
redirectTo: ... }`) that is returned as the second argument to the `onSuccess`
callback; ensure the description near `scope` (`Scopes[]`) and `hasSuccessPage`
(`boolean`) remains unchanged and reference the `state` usage shown in the
example.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx (1)
1066-1066: KeeploginHintargument concise and link to canonical format docs.The API reference currently embeds detailed format variants inline. Consider shortening this entry and linking to the dedicated auth configuration page to avoid duplication drift.
Based on learnings: In MDX documentation files (e.g., API references), prefer listing parameters in the Arguments section and linking to detailed documentation pages instead of duplicating descriptions, format specs, or validation rules inline.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx` at line 1066, Replace the verbose format examples for the loginHint parameter with a concise description and add a link to the canonical auth configuration docs; specifically update the Arguments entry for loginHint (the **`loginHint`** parameter) to a short phrase like "Optional login hint (see auth configuration for allowed formats)" and append a link to the dedicated auth/configuration page so detailed format variants are not duplicated in react-sdk.mdx.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx`:
- Line 221: Update user-facing copy to use hyphenated compound words for
consistency: change "sign in" and "sign up" to "sign-in" and "sign-up", "client
side" to "client-side", "logged in" to "logged-in", and "2 letter" to "2-letter"
wherever they appear in this doc; specifically update the sentence referencing
the logout method and LogoutLink component (the line mentioning `logout` and
`LogoutLink`) and apply the same hyphenation corrections to the other
occurrences noted in the review (the other referenced lines) so all user-facing
instances match the proposed hyphenation style.
- Line 1073: The docs incorrectly mark the login() and register() option
redirectURL as required; update the documentation for the login() and register()
argument descriptions to show redirectURL is optional (an override of
KindeProvider.redirectUri) rather than required—locate the lines in the React
SDK doc where **`redirectURL`** is documented for the login() and register()
methods and change the text from "(required)" to "(optional) - overrides
KindeProvider.redirectUri" so it matches the Aside and actual behavior.
---
Nitpick comments:
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx`:
- Line 1066: Replace the verbose format examples for the loginHint parameter
with a concise description and add a link to the canonical auth configuration
docs; specifically update the Arguments entry for loginHint (the **`loginHint`**
parameter) to a short phrase like "Optional login hint (see auth configuration
for allowed formats)" and append a link to the dedicated auth/configuration page
so detailed format variants are not duplicated in react-sdk.mdx.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx (1)
1066-1066: Prefer a briefloginHintdescription and link to canonical format docs.Keeping format/validation examples inline here increases drift risk. Keep this argument concise and link out to the dedicated auth-format docs.
Suggested wording
-- **`loginHint`** (`string`) - Login hint to use for the login. Can be in formats: `joe@blogs.com`, `phone:+447700900000:gb`, or `username:joebloggs` +- **`loginHint`** (`string`) - Login hint used to prefill the identity field. See [custom authentication pages](/authenticate/custom-configurations/custom-authentication-pages/) for accepted formats and validation.Based on learnings: "In MDX documentation files (e.g., any API reference docs), when documenting parameters (like loginHint, connectionId), prefer listing them in the API reference Arguments section and link to detailed documentation pages instead of duplicating descriptions, format specs, or validation rules inline."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx` at line 1066, Replace the verbose inline format/validation examples for the `loginHint` parameter with a concise one-line description and an explicit link to the canonical auth-format documentation; update the API reference "Arguments" entry for `loginHint` to read something like "login hint (string) — see [Auth formats] for allowed formats" and remove the example formats from this MDX so the detailed format/validation lives only in the dedicated auth-format docs referenced by the link.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx`:
- Around line 799-810: The docs show a mismatched getFlag signature and
incorrect code fences: change the documented API signature from code: string,
defaultValue?: string, type?: "string" | "boolean" | "number" to code: string,
options?: { defaultValue?: string | boolean | number; type?: "string" |
"boolean" | "number"; } and update all example blocks that use TypeScript
generics (e.g., getFlag<boolean>(), getFlag<number>()) to use tsx fences instead
of jsx; also update the CompetitionButton example and other examples to
demonstrate both single-arg usage (await getFlag('theme')) and typed generic
usage (await getFlag<boolean>('create_competition')) consistent with the new
options object form.
---
Nitpick comments:
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx`:
- Line 1066: Replace the verbose inline format/validation examples for the
`loginHint` parameter with a concise one-line description and an explicit link
to the canonical auth-format documentation; update the API reference "Arguments"
entry for `loginHint` to read something like "login hint (string) — see [Auth
formats] for allowed formats" and remove the example formats from this MDX so
the detailed format/validation lives only in the dedicated auth-format docs
referenced by the link.
signature
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx (1)
1066-1066: Reduce inline format-spec detail forloginHintin API reference.Keeping format rules inline here increases drift risk. Prefer a short argument description and link to the dedicated auth/customization docs for full accepted formats.
Based on learnings: In MDX documentation files (e.g., API reference docs), when documenting parameters, prefer listing them in the Arguments section and link to detailed documentation pages instead of duplicating descriptions, format specs, or validation rules inline.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx` at line 1066, Shorten the inline `loginHint` description in the API reference by removing the detailed format examples and instead use a concise argument description like "`loginHint` (string) - optional login hint; see authentication/customization docs for supported formats", and add a hyperlink to the dedicated auth/customization doc in the Arguments section so readers can find the full accepted formats and validation rules; update the `loginHint` entry in the Arguments block to reflect this change (refer to the `loginHint` parameter in the current MDX).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx`:
- Line 870: Fix the typo in the documentation sentence for the SDK methods:
update the phrase "accepts an `state` key" to read "accepts a `state` key" in
the description of the options argument for the login and register methods so
the sentence correctly references the `state` key returned in the second
argument to the onSuccess callback.
- Around line 908-909: Update the wording around Kinde custom domain and
useInsecureForRefreshToken to avoid stating httpOnly cookies are "not vulnerable
to CSRF attacks"; instead clarify that httpOnly prevents JavaScript access but
CSRF protections depend on SameSite, origin checks, and other anti-CSRF
measures. Specifically, edit the two bullets mentioning the custom domain and
useInsecureForRefreshToken to say: store the refresh token in a secure, httpOnly
cookie on your custom domain (which prevents JS access) and ensure you also use
SameSite, proper origin/CSRF checks, or other anti-CSRF protections; and keep
the note that useInsecureForRefreshToken is only for local development and
stores the refresh token in local storage (not suitable for production).
Reference the terms "Kinde custom domain" and "useInsecureForRefreshToken" when
making these changes.
- Around line 1251-1254: Replace the JWT-like string examples for accessToken,
idToken, and refreshToken with clearly fake placeholders to avoid secret-scan
noise; update the example object (the keys accessToken, idToken, refreshToken)
to use explicit non-secrets such as "<ACCESS_TOKEN_PLACEHOLDER>",
"<ID_TOKEN_PLACEHOLDER>", and "<REFRESH_TOKEN_PLACEHOLDER>" (keep success: true
as-is).
---
Nitpick comments:
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx`:
- Line 1066: Shorten the inline `loginHint` description in the API reference by
removing the detailed format examples and instead use a concise argument
description like "`loginHint` (string) - optional login hint; see
authentication/customization docs for supported formats", and add a hyperlink to
the dedicated auth/customization doc in the Arguments section so readers can
find the full accepted formats and validation rules; update the `loginHint`
entry in the Arguments block to reflect this change (refer to the `loginHint`
parameter in the current MDX).
|
|
||
| ## Persisting application state | ||
|
|
||
| The options argument passed into the `login` and `register` methods accepts an `state` key where you can pass in the current application state prior to redirecting to Kinde. This is then returned to you in the second argument of the `onSuccess` callback as seen above. |
There was a problem hiding this comment.
Fix article typo in the state description.
Line 870 says “accepts an state key”; this should be “a state key.”
Suggested fix
-The options argument passed into the `login` and `register` methods accepts an `state` key where you can pass in the current application state prior to redirecting to Kinde.
+The options argument passed into the `login` and `register` methods accepts a `state` key where you can pass in the current application state prior to redirecting to Kinde.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| The options argument passed into the `login` and `register` methods accepts an `state` key where you can pass in the current application state prior to redirecting to Kinde. This is then returned to you in the second argument of the `onSuccess` callback as seen above. | |
| The options argument passed into the `login` and `register` methods accepts a `state` key where you can pass in the current application state prior to redirecting to Kinde. This is then returned to you in the second argument of the `onSuccess` callback as seen above. |
🧰 Tools
🪛 LanguageTool
[style] ~870-~870: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...n pass in the current application state prior to redirecting to Kinde. This is then retu...
(EN_WORDINESS_PREMIUM_PRIOR_TO)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx` at line 870,
Fix the typo in the documentation sentence for the SDK methods: update the
phrase "accepts an `state` key" to read "accepts a `state` key" in the
description of the options argument for the login and register methods so the
sentence correctly references the `state` key returned in the second argument to
the onSuccess callback.
| 1. Use the Kinde custom domain feature. We can then set a secure, httpOnly cookie against your domain containing only the refresh token which is not vulnerable to CSRF attacks. | ||
| 2. There is an escape hatch which can be used for local development: `useInsecureForRefreshToken`. This SHOULD NOT be used in production. We recommend you use a custom domain. This will store only the refresh token in local storage and is used to silently re-authenticate. |
There was a problem hiding this comment.
Avoid claiming httpOnly cookies are immune to CSRF.
Line 908 currently states the refresh-token cookie is “not vulnerable to CSRF attacks.” That’s too absolute and can mislead implementers. httpOnly mitigates JavaScript access (XSS impact), but CSRF still depends on controls like SameSite, origin checks, and anti-CSRF protections.
Suggested wording update
-1. Use the Kinde custom domain feature. We can then set a secure, httpOnly cookie against your domain containing only the refresh token which is not vulnerable to CSRF attacks.
+1. Use the Kinde custom domain feature. We can then set a secure, httpOnly cookie against your domain containing only the refresh token. This reduces token exposure to JavaScript; CSRF protection still relies on controls such as SameSite and server-side request validation.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx` around lines
908 - 909, Update the wording around Kinde custom domain and
useInsecureForRefreshToken to avoid stating httpOnly cookies are "not vulnerable
to CSRF attacks"; instead clarify that httpOnly prevents JavaScript access but
CSRF protections depend on SameSite, origin checks, and other anti-CSRF
measures. Specifically, edit the two bullets mentioning the custom domain and
useInsecureForRefreshToken to say: store the refresh token in a secure, httpOnly
cookie on your custom domain (which prevents JS access) and ensure you also use
SameSite, proper origin/CSRF checks, or other anti-CSRF protections; and keep
the note that useInsecureForRefreshToken is only for local development and
stores the refresh token in local storage (not suitable for production).
Reference the terms "Kinde custom domain" and "useInsecureForRefreshToken" when
making these changes.
| success: true, | ||
| accessToken: "eyJhbGciOiJIUzI1NiIsInR5c...", | ||
| idToken: "eyJhbGciOiJIUzI1NiIsInR5c...", | ||
| refreshToken: "eyJhbGciOiJIUzI1NiIsInR5c..." |
There was a problem hiding this comment.
Use clearly fake placeholders in token output examples to reduce secret-scan noise.
These JWT-like values are triggering gitleaks warnings. Replacing them with explicit placeholders makes docs safer and keeps CI cleaner.
Suggested fix
{
success: true,
- accessToken: "eyJhbGciOiJIUzI1NiIsInR5c...",
- idToken: "eyJhbGciOiJIUzI1NiIsInR5c...",
- refreshToken: "eyJhbGciOiJIUzI1NiIsInR5c..."
+ accessToken: "<access_token>",
+ idToken: "<id_token>",
+ refreshToken: "<refresh_token>"
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| success: true, | |
| accessToken: "eyJhbGciOiJIUzI1NiIsInR5c...", | |
| idToken: "eyJhbGciOiJIUzI1NiIsInR5c...", | |
| refreshToken: "eyJhbGciOiJIUzI1NiIsInR5c..." | |
| { | |
| success: true, | |
| accessToken: "<access_token>", | |
| idToken: "<id_token>", | |
| refreshToken: "<refresh_token>" | |
| } |
🧰 Tools
🪛 Gitleaks (8.30.0)
[high] 1252-1252: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
[high] 1253-1253: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
[high] 1254-1254: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/content/docs/developer-tools/sdks/frontend/react-sdk.mdx` around lines
1251 - 1254, Replace the JWT-like string examples for accessToken, idToken, and
refreshToken with clearly fake placeholders to avoid secret-scan noise; update
the example object (the keys accessToken, idToken, refreshToken) to use explicit
non-secrets such as "<ACCESS_TOKEN_PLACEHOLDER>", "<ID_TOKEN_PLACEHOLDER>", and
"<REFRESH_TOKEN_PLACEHOLDER>" (keep success: true as-is).
1 participant
Description (required)
Updates the React SDK docs to be more developer-friendly.
Related issues & labels (optional)
Summary by CodeRabbit
Documentation
New Features (docs-visible)