Conversation
…. A placeholder for verifyProof updates
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
madhavanmalolan seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
📝 WalkthroughWalkthroughAdds a Next.js GET route at Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Client (browser/curl)
participant Next as Next.js server
participant FS as Filesystem (`content/docs`)
Client->>Next: GET /some/path.md
Note right of Next: next.config rewrite maps to /api/raw/some/path
Next->>Next: invoke app/api/raw/[...slug]/GET
Next->>FS: check candidate files ("some/path.mdx", "some/path/index.mdx")\nverify path startsWith contentDir
FS-->>Next: file content (or error)
Next-->>Client: 200 text/markdown with file body\nor 404 JSON { error: "Not found" }
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
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 |
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
content/docs/react-native/usage.mdx (1)
38-69:⚠️ Potential issue | 🟡 MinorUpdate stale JS SDK links in React Native usage guide.
Line 38 and Line 69 reference pages removed in this PR (
/js-sdk/preparing-requestand/js-sdk/verifying-proofs). Please point both to existing JS SDK docs (e.g.,/js-sdk/usagewith valid anchors).Suggested fix
-1. Export the session config from your backend using `request.toJsonString()` (see [how to setup a request on the backend](/js-sdk/preparing-request#setup-a-request-on-the-backend)). +1. Export the session config from your backend using `request.toJsonString()` (see [how to set up a request on the backend](/js-sdk/usage)). -After the verification is completed, you can submit and verify the proofs on your backend server using our [JS SDK](/js-sdk/verifying-proofs#verify-the-proof). +After verification completes, submit and verify proofs on your backend server using our [JS SDK](/js-sdk/usage).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@content/docs/react-native/usage.mdx` around lines 38 - 69, Update the two stale JS SDK links in this file: replace the `/js-sdk/preparing-request#setup-a-request-on-the-backend` reference used with `request.toJsonString()` and the `/js-sdk/verifying-proofs#verify-the-proof` reference in the "Verify the Result" section with the current JS SDK doc path (e.g., `/js-sdk/usage` plus appropriate anchors) so that the guidance for using reclaimVerification.startVerificationFromJson / request.toJsonString() and verifying proofs on the backend (reclaimVerification.startVerification, verify flow) points to existing, correct documentation.content/docs/index.mdx (1)
100-100:⚠️ Potential issue | 🟡 MinorTypo: trailing "/" should be "."
-If you want custom themes to match your branding, you can [contact us](https://t.me/protocolreclaim)/ +If you want custom themes to match your branding, you can [contact us](https://t.me/protocolreclaim).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@content/docs/index.mdx` at line 100, Fix the typo where a sentence in the docs ends with a trailing "/" instead of a period: locate the sentence in content/docs/index.mdx that currently ends with "/" and replace that trailing slash with a "." so the sentence ends with a proper period.
🧹 Nitpick comments (4)
content/docs/js-sdk/usage.mdx (2)
277-277: Spelling: "atleast" → "at least".✏️ Proposed fixes
- - If proofs is an array, this will make sure that each proof corresponds to atleast one of the given provider hashes. + - If proofs is an array, this will make sure that each proof corresponds to at least one of the given provider hashes.- - `required` : does atleast one proof in `proofs` need to match this provider hash? Defaults to `false`. + - `required` : does at least one proof in `proofs` need to match this provider hash? Defaults to `false`.Also applies to: 286-286
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@content/docs/js-sdk/usage.mdx` at line 277, Fix the spelling of "atleast" to "at least" in the two occurrences of the sentence starting "If proofs is an array, this will make sure that each proof corresponds to atleast one of the given provider hashes." (occurrences near the "If proofs is an array..." text at the two reported spots); update both instances to read "at least" so they become "each proof corresponds to at least one of the given provider hashes."
104-107: Useprocess.envconsistently for credentials in examples.The main init example (lines 21-25) correctly uses
process.env.RECLAIMPROTOCOL_APP_IDandprocess.env.RECLAIMPROTOCOL_APP_SECRET, but these nested examples use bareAPP_ID,APP_SECRET,PROVIDER_IDvariables. This inconsistency could mislead developers into hardcoding credentials.As per coding guidelines: "Use environment variables for APP_ID, APP_SECRET, and PROVIDER_ID credentials."
♻️ Proposed fix for lines 104-107
const proofRequest = await ReclaimProofRequest.init(APP_ID, APP_SECRET, PROVIDER_ID, { +// Use process.env.RECLAIMPROTOCOL_APP_ID, process.env.RECLAIMPROTOCOL_APP_SECRET, 'your-provider-id' metadata: { theme: 'dark' }, });Or update to match the main example pattern:
const proofRequest = await ReclaimProofRequest.init( process.env.RECLAIMPROTOCOL_APP_ID, process.env.RECLAIMPROTOCOL_APP_SECRET, 'your-provider-id', { metadata: { theme: 'dark' } } );Also applies to: 124-127
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@content/docs/js-sdk/usage.mdx` around lines 104 - 107, Replace the hardcoded/placeholder variables used in the ReclaimProofRequest.init call (APP_ID, APP_SECRET, PROVIDER_ID) with the environment variable pattern used elsewhere (e.g. process.env.RECLAIMPROTOCOL_APP_ID, process.env.RECLAIMPROTOCOL_APP_SECRET and either process.env.RECLAIMPROTOCOL_PROVIDER_ID or a clear 'your-provider-id' placeholder); update the example invocation of ReclaimProofRequest.init accordingly so the snippet is consistent with the main example and coding guidelines.app/api/raw/[...slug]/route.ts (1)
32-34: Consider catching only file-not-found errors.The empty
catchblock swallows all errors, including unexpected ones like permission errors (EACCES) or too many open files (EMFILE). Consider checking forENOENTspecifically and re-throwing unexpected errors.♻️ Proposed refinement
- } catch { - // Try next candidate - } + } catch (err: unknown) { + if ((err as NodeJS.ErrnoException).code !== 'ENOENT') { + throw err; + } + // File not found, try next candidate + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/api/raw/`[...slug]/route.ts around lines 32 - 34, The empty catch in app/api/raw/[...slug]/route.ts is swallowing all errors; change it to capture the error (e.g., catch (err)) and only ignore file-not-found by checking err.code === 'ENOENT' (or Node's built-in constants), otherwise re-throw the error so permission/EMFILE and other unexpected errors bubble up; update the catch block surrounding the file-open/lookup logic (the try/catch that currently contains "// Try next candidate") to implement this conditional rethrow.content/docs/index.mdx (1)
55-59: Minor spelling/grammar issues.A few small corrections based on static analysis:
- Line 55: "usecases" → "use cases" (two words)
- Line 59: "etc" → "etc." (needs period in American English)
✏️ Proposed fixes
-However, there are some hero usecases that work out of the box : +However, there are some hero use cases that work out of the box:-4. Finance verification (Coming soon) - Creditscores, accredited investor status, tax documents etc. +4. Finance verification (Coming soon) - Credit scores, accredited investor status, tax documents, etc.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@content/docs/index.mdx` around lines 55 - 59, The bulleted numbered list in the documentation contains minor grammar issues: replace the single-word "usecases" with the two-word phrase "use cases" (occurs in the sentence starting "However, there are some hero usecases...") and add a trailing period to "etc" (change "etc" to "etc.") in the Finance verification line to conform to American English punctuation; update those exact tokens in content/docs/index.mdx so the list reads "use cases" and "etc." respectively.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@app/api/raw/`[...slug]/route.ts:
- Around line 19-23: The path traversal check in the loop over candidates is
ineffective because it compares the unnormalized filePath (produced with
path.join) using startsWith; normalize and compare absolute paths instead by
resolving both the candidate path and the contentDir (use path.resolve) and
ensure the resolved candidate has the contentDir plus path.sep as its prefix;
update the check around the loop that currently examines filePath and contentDir
(variables/filePath, contentDir, and use of path.join) to reject any candidate
whose resolved path does not start with path.resolve(contentDir) + path.sep.
In `@content/docs/api-key.mdx`:
- Line 38: In content/docs/api-key.mdx the Card component's href attribute for
the "React Native" card mistakenly uses "/reactnative/install" which will 404;
update the Card href value (the Card element with title "React Native") to the
correct route "/react-native/install" so it matches the docs route structure.
In `@content/docs/index.mdx`:
- Line 34: Replace the incorrect phrase "The logs in into a website where the
information they want to verify exists." with a correct subject-verb form such
as "They log in to a website where the information they want to verify exists."
or "The user logs in to a website where the information they want to verify
exists." — locate the exact sentence in the content block ("The logs in into a
website...") and update it to use "log in to" with a clear subject ("They" or
"The user").
In `@content/docs/js-sdk/usage.mdx`:
- Line 238: The link currently pointing to the removed page
(/js-sdk/preparing-request#what-triggers-cancel-callback) is broken; update the
link in content/docs/js-sdk/usage.mdx to reference the internal anchor that
exists in this file (`#what-triggers-cancel-callback`) so it points to the
existing section within usage.mdx (replace the external path with the local
anchor).
In `@public/llms.txt`:
- Around line 13-16: The heading "JS SDK (Web)" should be renamed to "NodeJS
SDK" to match the new docs taxonomy; update the heading text in public/llms.txt
(replace the exact string "JS SDK (Web)" with "NodeJS SDK") and verify the list
entries below ("JS SDK Installation", "JS SDK Usage") are updated to match
naming if needed so the displayed SDK names align with the docs.
---
Outside diff comments:
In `@content/docs/index.mdx`:
- Line 100: Fix the typo where a sentence in the docs ends with a trailing "/"
instead of a period: locate the sentence in content/docs/index.mdx that
currently ends with "/" and replace that trailing slash with a "." so the
sentence ends with a proper period.
In `@content/docs/react-native/usage.mdx`:
- Around line 38-69: Update the two stale JS SDK links in this file: replace the
`/js-sdk/preparing-request#setup-a-request-on-the-backend` reference used with
`request.toJsonString()` and the `/js-sdk/verifying-proofs#verify-the-proof`
reference in the "Verify the Result" section with the current JS SDK doc path
(e.g., `/js-sdk/usage` plus appropriate anchors) so that the guidance for using
reclaimVerification.startVerificationFromJson / request.toJsonString() and
verifying proofs on the backend (reclaimVerification.startVerification, verify
flow) points to existing, correct documentation.
---
Nitpick comments:
In `@app/api/raw/`[...slug]/route.ts:
- Around line 32-34: The empty catch in app/api/raw/[...slug]/route.ts is
swallowing all errors; change it to capture the error (e.g., catch (err)) and
only ignore file-not-found by checking err.code === 'ENOENT' (or Node's built-in
constants), otherwise re-throw the error so permission/EMFILE and other
unexpected errors bubble up; update the catch block surrounding the
file-open/lookup logic (the try/catch that currently contains "// Try next
candidate") to implement this conditional rethrow.
In `@content/docs/index.mdx`:
- Around line 55-59: The bulleted numbered list in the documentation contains
minor grammar issues: replace the single-word "usecases" with the two-word
phrase "use cases" (occurs in the sentence starting "However, there are some
hero usecases...") and add a trailing period to "etc" (change "etc" to "etc.")
in the Finance verification line to conform to American English punctuation;
update those exact tokens in content/docs/index.mdx so the list reads "use
cases" and "etc." respectively.
In `@content/docs/js-sdk/usage.mdx`:
- Line 277: Fix the spelling of "atleast" to "at least" in the two occurrences
of the sentence starting "If proofs is an array, this will make sure that each
proof corresponds to atleast one of the given provider hashes." (occurrences
near the "If proofs is an array..." text at the two reported spots); update both
instances to read "at least" so they become "each proof corresponds to at least
one of the given provider hashes."
- Around line 104-107: Replace the hardcoded/placeholder variables used in the
ReclaimProofRequest.init call (APP_ID, APP_SECRET, PROVIDER_ID) with the
environment variable pattern used elsewhere (e.g.
process.env.RECLAIMPROTOCOL_APP_ID, process.env.RECLAIMPROTOCOL_APP_SECRET and
either process.env.RECLAIMPROTOCOL_PROVIDER_ID or a clear 'your-provider-id'
placeholder); update the example invocation of ReclaimProofRequest.init
accordingly so the snippet is consistent with the main example and coding
guidelines.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 80efeeba-4982-4272-aa43-ecbabfdf8c5b
📒 Files selected for processing (25)
app/api/raw/[...slug]/route.tscontent/docs/analytics-dashboard.mdxcontent/docs/api-key.mdxcontent/docs/fully-hosted/bundles/age.mdxcontent/docs/fully-hosted/bundles/default.mdxcontent/docs/fully-hosted/bundles/education.mdxcontent/docs/fully-hosted/bundles/employment.mdxcontent/docs/fully-hosted/bundles/meta.jsoncontent/docs/fully-hosted/index.mdxcontent/docs/fully-hosted/installation.mdxcontent/docs/fully-hosted/meta.jsoncontent/docs/fully-hosted/usage.mdxcontent/docs/index.mdxcontent/docs/js-sdk/generating-proof.mdxcontent/docs/js-sdk/installation.mdxcontent/docs/js-sdk/meta.jsoncontent/docs/js-sdk/preparing-request.mdxcontent/docs/js-sdk/usage.mdxcontent/docs/js-sdk/verifying-proofs.mdxcontent/docs/meta.jsoncontent/docs/react-native/install/index.mdxcontent/docs/react-native/meta.jsoncontent/docs/react-native/usage.mdxnext.config.mjspublic/llms.txt
💤 Files with no reviewable changes (14)
- content/docs/meta.json
- content/docs/fully-hosted/bundles/employment.mdx
- content/docs/fully-hosted/bundles/meta.json
- content/docs/fully-hosted/bundles/education.mdx
- content/docs/fully-hosted/installation.mdx
- content/docs/fully-hosted/index.mdx
- content/docs/fully-hosted/meta.json
- content/docs/fully-hosted/bundles/age.mdx
- content/docs/fully-hosted/usage.mdx
- content/docs/js-sdk/verifying-proofs.mdx
- content/docs/js-sdk/preparing-request.mdx
- content/docs/analytics-dashboard.mdx
- content/docs/fully-hosted/bundles/default.mdx
- content/docs/js-sdk/generating-proof.mdx
| for (const filePath of candidates) { | ||
| // Prevent path traversal | ||
| if (!filePath.startsWith(contentDir)) { | ||
| return NextResponse.json({ error: 'Not found' }, { status: 404 }); | ||
| } |
There was a problem hiding this comment.
Path traversal protection is ineffective due to path.join not resolving .. sequences.
The current check compares filePath against contentDir using startsWith, but path.join() does not normalize .. segments. An attacker can pass slug = ['..', '..', 'etc', 'passwd'] which produces content/docs/../../etc/passwd — this string still starts with content/docs but resolves outside it.
Use path.resolve() to normalize both paths before comparison:
🔒 Proposed fix for path traversal vulnerability
for (const filePath of candidates) {
+ const resolvedPath = path.resolve(filePath);
+ const resolvedContentDir = path.resolve(contentDir);
// Prevent path traversal
- if (!filePath.startsWith(contentDir)) {
+ if (!resolvedPath.startsWith(resolvedContentDir + path.sep)) {
return NextResponse.json({ error: 'Not found' }, { status: 404 });
}Note: Adding + path.sep ensures content/docs-evil doesn't match content/docs.
📝 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.
| for (const filePath of candidates) { | |
| // Prevent path traversal | |
| if (!filePath.startsWith(contentDir)) { | |
| return NextResponse.json({ error: 'Not found' }, { status: 404 }); | |
| } | |
| for (const filePath of candidates) { | |
| const resolvedPath = path.resolve(filePath); | |
| const resolvedContentDir = path.resolve(contentDir); | |
| // Prevent path traversal | |
| if (!resolvedPath.startsWith(resolvedContentDir + path.sep)) { | |
| return NextResponse.json({ error: 'Not found' }, { status: 404 }); | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@app/api/raw/`[...slug]/route.ts around lines 19 - 23, The path traversal
check in the loop over candidates is ineffective because it compares the
unnormalized filePath (produced with path.join) using startsWith; normalize and
compare absolute paths instead by resolving both the candidate path and the
contentDir (use path.resolve) and ensure the resolved candidate has the
contentDir plus path.sep as its prefix; update the check around the loop that
currently examines filePath and contentDir (variables/filePath, contentDir, and
use of path.join) to reject any candidate whose resolved path does not start
with path.resolve(contentDir) + path.sep.
| <Card href="/flutter/installation" title="Flutter"> | ||
| Most stable mobile SDK. | ||
| </Card> | ||
| <Card href="/reactnative/install" title="React Native"> |
There was a problem hiding this comment.
Fix the React Native docs route typo.
Line 38 links to /reactnative/install, but the docs route structure uses /react-native/.... This will likely 404.
Suggested fix
- <Card href="/reactnative/install" title="React Native">
+ <Card href="/react-native/install" title="React Native">📝 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.
| <Card href="/reactnative/install" title="React Native"> | |
| <Card href="/react-native/install" title="React Native"> |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@content/docs/api-key.mdx` at line 38, In content/docs/api-key.mdx the Card
component's href attribute for the "React Native" card mistakenly uses
"/reactnative/install" which will 404; update the Card href value (the Card
element with title "React Native") to the correct route "/react-native/install"
so it matches the docs route structure.
| ## Issues with the traditional way | ||
| - If you are verifying manually, well ... it will take time and resources to actually verify | ||
| - You are at the mercy of the user to upload authentic PDFs and not morphed ones | ||
| 1. The logs in into a website where the information they want to verify exists. That is, Acme Corp's payroll system. |
There was a problem hiding this comment.
Typo: "The logs in" should be "They log in" or "The user logs in".
✏️ Proposed fix
-1. The logs in into a website where the information they want to verify exists. That is, Acme Corp's payroll system.
+1. They log in to a website where the information they want to verify exists. That is, Acme Corp's payroll system.📝 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.
| 1. The logs in into a website where the information they want to verify exists. That is, Acme Corp's payroll system. | |
| 1. They log in to a website where the information they want to verify exists. That is, Acme Corp's payroll system. |
🧰 Tools
🪛 LanguageTool
[style] ~34-~34: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...to a website where the information they want to verify exists. That is, Acme Corp's pay...
(REP_WANT_TO_VB)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@content/docs/index.mdx` at line 34, Replace the incorrect phrase "The logs in
into a website where the information they want to verify exists." with a correct
subject-verb form such as "They log in to a website where the information they
want to verify exists." or "The user logs in to a website where the information
they want to verify exists." — locate the exact sentence in the content block
("The logs in into a website...") and update it to use "log in to" with a clear
subject ("They" or "The user").
| ); | ||
| ``` | ||
|
|
||
| Redirection happens after cancel callback is invoked by reclaim. See [What triggers a Cancel Callback](/js-sdk/preparing-request#what-triggers-cancel-callback) for more details. |
There was a problem hiding this comment.
Broken internal link: preparing-request.mdx was removed.
The link /js-sdk/preparing-request#what-triggers-cancel-callback points to a file that was removed in this PR. The anchor #what-triggers-cancel-callback exists earlier in this same file (line 202).
🔗 Proposed fix
-Redirection happens after cancel callback is invoked by reclaim. See [What triggers a Cancel Callback](/js-sdk/preparing-request#what-triggers-cancel-callback) for more details.
+Redirection happens after cancel callback is invoked by Reclaim. See [What triggers cancel callback?](`#what-triggers-cancel-callback`) for more details.📝 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.
| Redirection happens after cancel callback is invoked by reclaim. See [What triggers a Cancel Callback](/js-sdk/preparing-request#what-triggers-cancel-callback) for more details. | |
| Redirection happens after cancel callback is invoked by Reclaim. See [What triggers cancel callback?](`#what-triggers-cancel-callback`) for more details. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@content/docs/js-sdk/usage.mdx` at line 238, The link currently pointing to
the removed page (/js-sdk/preparing-request#what-triggers-cancel-callback) is
broken; update the link in content/docs/js-sdk/usage.mdx to reference the
internal anchor that exists in this file (`#what-triggers-cancel-callback`) so it
points to the existing section within usage.mdx (replace the external path with
the local anchor).
| ## JS SDK (Web) | ||
|
|
||
| - [JS SDK Installation](https://docs.reclaimprotocol.org/js-sdk/installation.md) | ||
| - [JS SDK Usage](https://docs.reclaimprotocol.org/js-sdk/usage.md) |
There was a problem hiding this comment.
Align SDK naming with the new docs taxonomy.
Line 13 says “JS SDK (Web)” while the docs section is now “NodeJS SDK”. Please keep naming consistent to prevent confusion in indexed outputs.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@public/llms.txt` around lines 13 - 16, The heading "JS SDK (Web)" should be
renamed to "NodeJS SDK" to match the new docs taxonomy; update the heading text
in public/llms.txt (replace the exact string "JS SDK (Web)" with "NodeJS SDK")
and verify the list entries below ("JS SDK Installation", "JS SDK Usage") are
updated to match naming if needed so the displayed SDK names align with the
docs.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
content/docs/js-sdk/usage.mdx (1)
238-238:⚠️ Potential issue | 🟡 MinorBroken internal link to removed page.
The link
/js-sdk/preparing-request#what-triggers-cancel-callbackpoints to a file that was removed in this PR. The section "What triggers cancel callback?" exists in this file at line 202.🔗 Proposed fix
-Redirection happens after cancel callback is invoked by reclaim. See [What triggers a Cancel Callback](/js-sdk/preparing-request#what-triggers-cancel-callback) for more details. +Redirection happens after cancel callback is invoked by Reclaim. See [What triggers cancel callback?](`#what-triggers-cancel-callback`) for more details.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@content/docs/js-sdk/usage.mdx` at line 238, The internal link currently points to a removed page; update the link target to the existing "What triggers cancel callback?" section in this document by replacing /js-sdk/preparing-request#what-triggers-cancel-callback with the correct local anchor (e.g., `#what-triggers-cancel-callback`) or the correct page that contains that heading (the "What triggers cancel callback?" anchor in this file), so the sentence "See What triggers a Cancel Callback for more details." links to the actual section.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@content/docs/js-sdk/usage.mdx`:
- Line 286: Fix the grammar in the `required` description: change "does atleast
one proof in `proofs` need to match this provider hash?" to "does at least one
proof in `proofs` need to match this provider hash?" — update the text near the
`required` field in content/docs/js-sdk/usage.mdx so `atleast` becomes two words
(`at least`).
---
Duplicate comments:
In `@content/docs/js-sdk/usage.mdx`:
- Line 238: The internal link currently points to a removed page; update the
link target to the existing "What triggers cancel callback?" section in this
document by replacing /js-sdk/preparing-request#what-triggers-cancel-callback
with the correct local anchor (e.g., `#what-triggers-cancel-callback`) or the
correct page that contains that heading (the "What triggers cancel callback?"
anchor in this file), so the sentence "See What triggers a Cancel Callback for
more details." links to the actual section.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1c368836-60ad-4f1d-bb80-613d30bdc6cb
📒 Files selected for processing (1)
content/docs/js-sdk/usage.mdx
| const result = await verifyProof(proofs, [{ value: '0xF22..', multiple: false, required: true }]); | ||
| ``` | ||
| - `multiple` : can the hash match multiple proofs in the `proofs` array? Defaults to `true`. | ||
| - `required` : does atleast one proof in `proofs` need to match this provider hash? Defaults to `false`. |
There was a problem hiding this comment.
Grammar correction needed.
The phrase "does atleast one proof" should be "does at least one proof" (two words).
📝 Proposed fix
- - `required` : does atleast one proof in `proofs` need to match this provider hash? Defaults to `false`.
+ - `required` : does at least one proof in `proofs` need to match this provider hash? Defaults to `false`.📝 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.
| - `required` : does atleast one proof in `proofs` need to match this provider hash? Defaults to `false`. | |
| - `required` : does at least one proof in `proofs` need to match this provider hash? Defaults to `false`. |
🧰 Tools
🪛 LanguageTool
[grammar] ~286-~286: Ensure spelling is correct
Context: ...faults to true. - required : does atleast one proof in proofs need to match thi...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@content/docs/js-sdk/usage.mdx` at line 286, Fix the grammar in the `required`
description: change "does atleast one proof in `proofs` need to match this
provider hash?" to "does at least one proof in `proofs` need to match this
provider hash?" — update the text near the `required` field in
content/docs/js-sdk/usage.mdx so `atleast` becomes two words (`at least`).
|
|
||
| ### Open verification | ||
| ``` javascript | ||
| const proofRequestUrl = await reclaimProofRequest.getRequestUrl(); |
There was a problem hiding this comment.
can we add triggerReclaimFlow() an alternative to getRequestUrl() around (the "Open verification" section). Key capabilities:
- Verification modes: Accepts
{ verificationMode: 'portal' | 'app' }—'portal'(default) opens remote browser verification,'app'directs users to the verifier app via share page. - Embedded iframe: Pass
{ target: document.getElementById('container') }to load the portal inside a DOM element as an iframe instead of opening a new tab.
There was a problem hiding this comment.
I will add a separate section of other modes. I wanted this version to need no change on the frontend - hence no triggerReclaimFlow.
| ### Open verification | ||
| ``` javascript | ||
| const proofRequestUrl = await reclaimProofRequest.getRequestUrl(); | ||
|
|
There was a problem hiding this comment.
getRequestUrl() also accepts { verificationMode: 'portal' | 'app' } (defaults to 'portal').
const portalUrl = await reclaimProofRequest.getRequestUrl(); // default: portal
const appUrl = await reclaimProofRequest.getRequestUrl({ verificationMode: 'app' });There was a problem hiding this comment.
Again, omitting app based verification from js-sdk for now. I will add these front end options in a separate page.
Making websdk the only way to generate proofs using js-sdk (on instantapp, appclip)
Created a stub for verifyProof (needs to be updated based on actual signatures)
Summary by CodeRabbit
New Features
.mdrequests resolve to raw content.Documentation