[grid] Document passkey nickname validation#428
[grid] Document passkey nickname validation#428DhruvPareek wants to merge 1 commit into04-30-grid-auth-challenge-rate-limit-docsfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
✱ Stainless preview buildsThis PR will update the kotlin openapi python typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ✅ grid-openapi studio · code · diff
✅ grid-kotlin studio · code · diff
|
Greptile SummaryThis documentation-only PR adds passkey nickname validation rules to the OpenAPI spec — specifically that nicknames are 1–100 characters, allow Unicode letters/numbers/spaces/select separators, and have leading/trailing whitespace ignored. Both the source schema and the regenerated bundles ( Confidence Score: 4/5Safe to merge — documentation-only change with no logic or breaking schema modifications. Only P2 findings: missing machine-readable minLength/maxLength constraints and a minor wording ambiguity around whitespace handling. No functional or correctness issues. openapi/components/schemas/auth/PasskeyCredentialCreateRequestFields.yaml — consider adding minLength/maxLength alongside the prose validation rules.
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/auth/PasskeyCredentialCreateRequestFields.yaml | Added validation rules to the nickname description (1-100 chars, allowed character classes, whitespace handling); no machine-readable schema constraints added. |
| openapi/components/schemas/auth/AuthMethod.yaml | Minor wording update: "nickname provided" → "validated nickname provided" for PASSKEY credential type. |
| openapi.yaml | Regenerated bundle — reflects the same description changes from the source files correctly. |
| mintlify/openapi.yaml | Regenerated Mintlify bundle — identical changes to openapi.yaml, consistent with source. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Client submits passkey nickname] --> B[Strip leading & trailing whitespace]
B --> C{1–100 characters?}
C -- No --> D[Reject: validation error]
C -- Yes --> E{Only allowed characters?\nUnicode letters, numbers, spaces,\nperiod, underscore, hyphen,\napostrophe, parentheses}
E -- No --> D
E -- Yes --> F[Store validated nickname]
F --> G[AuthMethod response\nreturns validated nickname]
Comments Outside Diff (1)
-
openapi/components/schemas/auth/PasskeyCredentialCreateRequestFields.yaml, line 13-22 (link)Add
minLength/maxLengthconstraints to complement prose validation rulesThe description now correctly states "Must be 1-100 characters", but the schema itself has no
minLengthormaxLengthkeywords. Without these, OpenAPI validators and generated client SDKs won't enforce the constraint automatically. Consider adding them alongside the description:nickname: type: string minLength: 1 maxLength: 100 description: >- Human-readable identifier for the passkey, ...
This makes the constraint machine-readable, not just human-readable.
Prompt To Fix With AI
This is a comment left during a code review. Path: openapi/components/schemas/auth/PasskeyCredentialCreateRequestFields.yaml Line: 13-22 Comment: **Add `minLength`/`maxLength` constraints to complement prose validation rules** The description now correctly states "Must be 1-100 characters", but the schema itself has no `minLength` or `maxLength` keywords. Without these, OpenAPI validators and generated client SDKs won't enforce the constraint automatically. Consider adding them alongside the description: ```yaml nickname: type: string minLength: 1 maxLength: 100 description: >- Human-readable identifier for the passkey, ... ``` This makes the constraint machine-readable, not just human-readable. How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix All With AI
Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 2
openapi/components/schemas/auth/PasskeyCredentialCreateRequestFields.yaml:13-22
**Add `minLength`/`maxLength` constraints to complement prose validation rules**
The description now correctly states "Must be 1-100 characters", but the schema itself has no `minLength` or `maxLength` keywords. Without these, OpenAPI validators and generated client SDKs won't enforce the constraint automatically. Consider adding them alongside the description:
```yaml
nickname:
type: string
minLength: 1
maxLength: 100
description: >-
Human-readable identifier for the passkey, ...
```
This makes the constraint machine-readable, not just human-readable.
### Issue 2 of 2
openapi/components/schemas/auth/PasskeyCredentialCreateRequestFields.yaml:16-19
**"Whitespace is ignored" is ambiguous about the stored value**
"Leading and trailing whitespace is ignored" could mean (a) whitespace is stripped before storage, so the stored `nickname` has no leading/trailing whitespace, or (b) the API accepts whitespace but callers should trim it themselves. The `AuthMethod` response description says "validated nickname", which implies (a), but a reader of this field alone can't tell. A small wording tweak removes the ambiguity:
```suggestion
registration time (e.g. "iPhone Face-ID", "YubiKey 5C"). Leading
and trailing whitespace is stripped before storage. Must be 1-100 characters and may
```
Reviews (1): Last reviewed commit: "[grid] Document passkey nickname validat..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| Human-readable identifier for the passkey, chosen by the user at | ||
| registration time (e.g. "iPhone Face-ID", "YubiKey 5C"). Shown | ||
| back on `AuthMethod` responses and in credential listings. | ||
| registration time (e.g. "iPhone Face-ID", "YubiKey 5C"). Leading | ||
| and trailing whitespace is ignored. Must be 1-100 characters and may | ||
| contain Unicode letters, numbers, spaces, and the following separators: |
There was a problem hiding this comment.
"Leading and trailing whitespace is ignored" could mean (a) whitespace is stripped before storage, so the stored nickname has no leading/trailing whitespace, or (b) the API accepts whitespace but callers should trim it themselves. The AuthMethod response description says "validated nickname", which implies (a), but a reader of this field alone can't tell. A small wording tweak removes the ambiguity:
| Human-readable identifier for the passkey, chosen by the user at | |
| registration time (e.g. "iPhone Face-ID", "YubiKey 5C"). Shown | |
| back on `AuthMethod` responses and in credential listings. | |
| registration time (e.g. "iPhone Face-ID", "YubiKey 5C"). Leading | |
| and trailing whitespace is ignored. Must be 1-100 characters and may | |
| contain Unicode letters, numbers, spaces, and the following separators: | |
| registration time (e.g. "iPhone Face-ID", "YubiKey 5C"). Leading | |
| and trailing whitespace is stripped before storage. Must be 1-100 characters and may |
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/auth/PasskeyCredentialCreateRequestFields.yaml
Line: 16-19
Comment:
**"Whitespace is ignored" is ambiguous about the stored value**
"Leading and trailing whitespace is ignored" could mean (a) whitespace is stripped before storage, so the stored `nickname` has no leading/trailing whitespace, or (b) the API accepts whitespace but callers should trim it themselves. The `AuthMethod` response description says "validated nickname", which implies (a), but a reader of this field alone can't tell. A small wording tweak removes the ambiguity:
```suggestion
registration time (e.g. "iPhone Face-ID", "YubiKey 5C"). Leading
and trailing whitespace is stripped before storage. Must be 1-100 characters and may
```
How can I resolve this? If you propose a fix, please make it concise.1 participant
Summary
Test Plan
npm run lint:openapi