fix: add input validation for sn and price_id fields#12
fix: add input validation for sn and price_id fields#12Washio20 wants to merge 1 commit intostayforge:mainfrom
Conversation
, Closes stayforge#4) Add regex pattern validation (^[a-zA-Z0-9_-]+$) to sn and price_id fields across DeviceProperties, DeviceInput, DeviceUpdate, and DeviceInfo schemas in both openapi.yaml and openapi.json. This prevents Chinese characters and other non-ASCII input from being accepted in these fields. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis PR adds input validation patterns to OpenAPI specification files, constraining string fields across device, card, tenant, organization, and API key schemas to alphanumeric characters with hyphens and underscores, enforcing stricter validation rules on previously unvalidated identifiers. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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.
Pull request overview
This PR adds input validation to the sn (serial number) and price_id fields in the OpenAPI specification to prevent non-ASCII characters (particularly Chinese characters) from being accepted. The validation is implemented using the regex pattern ^[a-zA-Z0-9_-]+$, which restricts these fields to alphanumeric characters, underscores, and hyphens.
Changes:
- Added pattern validation
^[a-zA-Z0-9_-]+$tosnfield across DeviceProperties, DeviceInput, DeviceUpdate, and DeviceInfo schemas - Added pattern validation
^[a-zA-Z0-9_-]+$toprice_idfield in DeviceProperties and DeviceUpdate schemas - Changes applied consistently to both openapi.yaml and openapi.json files
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| openapi.yaml | Added pattern validation to sn and price_id fields in all relevant device schemas |
| openapi.json | Applied the same pattern validation as YAML file, maintaining consistency between specification formats |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
openapi.yaml (1)
1039-1048:⚠️ Potential issue | 🟠 Major
/v1/devices/sn/{sn}path parameter is missing the new pattern constraint.The PR adds
^[a-zA-Z0-9_-]+$to allsnbody fields to block non-ASCII input, but the path parameter for theGET /v1/devices/sn/{sn}endpoint was not updated. A request likeGET /v1/devices/sn/中文字符will still pass OpenAPI validation here, directly undermining the goal of Issue#3.🐛 Proposed fix
- name: sn in: path required: true schema: type: string minLength: 1 maxLength: 256 + pattern: ^[a-zA-Z0-9_-]+$ description: Device serial number example: SFVA78RABZ12345678🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@openapi.yaml` around lines 1039 - 1048, The path parameter schema for the GET /v1/devices/sn/{sn} endpoint is missing the new pattern constraint; update the parameter named "sn" in openapi.yaml (the parameters block for the /v1/devices/sn/{sn} path) to include "pattern": "^[a-zA-Z0-9_-]+$" alongside the existing type/minLength/maxLength so the path parameter enforces the same ASCII alphanumeric/underscore/dash restriction as the body fields.
🧹 Nitpick comments (3)
openapi.yaml (1)
5776-5791:snandprice_idfields inDevicePropertiesare missingminLength/maxLength.The
pattern: ^[a-zA-Z0-9_-]+$uses+so it implicitly enforces minLength=1, butmaxLengthis unconstrained. The/v1/devices/sn/{sn}path parameter already setsmaxLength: 256for the same field — these should be consistent. The same gap applies toDeviceInput.sn,DeviceUpdate.sn,DeviceInfo.sn, andDeviceUpdate.price_id.♻️ Proposed fix for `DeviceProperties.sn` and `DeviceProperties.price_id`
sn: type: string nullable: true + minLength: 1 + maxLength: 256 pattern: ^[a-zA-Z0-9_-]+$ description: Serial number of the device. ... price_id: type: string nullable: true + minLength: 1 + maxLength: 256 pattern: ^[a-zA-Z0-9_-]+$ description: Stripe price ID for billing purposes.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@openapi.yaml` around lines 5776 - 5791, Add explicit minLength: 1 and maxLength: 256 to the sn property in DeviceProperties and mirror the same constraints for DeviceInput.sn, DeviceUpdate.sn, and DeviceInfo.sn so they match the /v1/devices/sn/{sn} path parameter; likewise add minLength: 1 and maxLength: 256 to DeviceUpdate.price_id (and any other price_id declarations) to constrain the pattern-based fields consistently. Locate the YAML schemas for DeviceProperties, DeviceInput, DeviceUpdate, and DeviceInfo and update the sn and price_id entries to include minLength: 1 and maxLength: 256.openapi.json (2)
7506-7510: Align /v1/devices/sn/{sn} path param with the SN regex.Right now the path parameter schema doesn’t include the new constraint, so the docs are inconsistent with the schema objects. Consider adding the same pattern.
🔧 Suggested update (path parameter)
"schema": { "type": "string", "minLength": 1, - "maxLength": 256 + "maxLength": 256, + "pattern": "^[a-zA-Z0-9_-]+$" }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@openapi.json` around lines 7506 - 7510, The path parameter definition for /v1/devices/sn/{sn} is missing the serial-number pattern defined in the shared schema 'sn'; update the path parameter (parameter name "sn" on the /v1/devices/sn/{sn} operation) to include the same "pattern": "^[a-zA-Z0-9_-]+$" (and type: "string" and description matching the shared schema) so the path parameter validation and docs match the "sn" schema object.
7308-7325: Reconsider strict format validation for Stripe price_id.The pattern
^[a-zA-Z0-9_-]+$is actually too restrictive for Stripe price IDs. Stripe generates Price IDs as opaque identifiers (e.g.,price_1MoBy5LkdIwHu7ixZhnattbh) and does not publish a strict regex. Per Stripe's official guidance, avoid format validation in your schema; instead, rely on API-level validation when a price is actually used. If you must validate in the schema, use a minimal check (non-empty string, optionally prefixed withprice_) rather than character-set restrictions.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@openapi.json` around lines 7308 - 7325, The "price_id" schema currently enforces pattern "^[a-zA-Z0-9_-]+$", which is too restrictive for Stripe price IDs; update the OpenAPI schema entry for the price_id property to remove or relax the pattern validation (e.g., remove the pattern and rely on nullable/string types with minLength:1 or replace with a minimal pattern like '^price_.+' if you must enforce a prefix), keeping the existing "type":"string" and "nullable":true and the description intact so API-level Stripe validation handles actual ID correctness; locate the "price_id" property in the schema to apply this change.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
openapi.jsonopenapi.yaml
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@openapi.yaml`:
- Around line 1039-1048: The path parameter schema for the GET
/v1/devices/sn/{sn} endpoint is missing the new pattern constraint; update the
parameter named "sn" in openapi.yaml (the parameters block for the
/v1/devices/sn/{sn} path) to include "pattern": "^[a-zA-Z0-9_-]+$" alongside the
existing type/minLength/maxLength so the path parameter enforces the same ASCII
alphanumeric/underscore/dash restriction as the body fields.
---
Nitpick comments:
In `@openapi.json`:
- Around line 7506-7510: The path parameter definition for /v1/devices/sn/{sn}
is missing the serial-number pattern defined in the shared schema 'sn'; update
the path parameter (parameter name "sn" on the /v1/devices/sn/{sn} operation) to
include the same "pattern": "^[a-zA-Z0-9_-]+$" (and type: "string" and
description matching the shared schema) so the path parameter validation and
docs match the "sn" schema object.
- Around line 7308-7325: The "price_id" schema currently enforces pattern
"^[a-zA-Z0-9_-]+$", which is too restrictive for Stripe price IDs; update the
OpenAPI schema entry for the price_id property to remove or relax the pattern
validation (e.g., remove the pattern and rely on nullable/string types with
minLength:1 or replace with a minimal pattern like '^price_.+' if you must
enforce a prefix), keeping the existing "type":"string" and "nullable":true and
the description intact so API-level Stripe validation handles actual ID
correctness; locate the "price_id" property in the schema to apply this change.
In `@openapi.yaml`:
- Around line 5776-5791: Add explicit minLength: 1 and maxLength: 256 to the sn
property in DeviceProperties and mirror the same constraints for DeviceInput.sn,
DeviceUpdate.sn, and DeviceInfo.sn so they match the /v1/devices/sn/{sn} path
parameter; likewise add minLength: 1 and maxLength: 256 to DeviceUpdate.price_id
(and any other price_id declarations) to constrain the pattern-based fields
consistently. Locate the YAML schemas for DeviceProperties, DeviceInput,
DeviceUpdate, and DeviceInfo and update the sn and price_id entries to include
minLength: 1 and maxLength: 256.
Summary
^[a-zA-Z0-9_-]+$) to thesn(serial number) field to reject Chinese characters and other non-ASCII inputprice_idfield to enforce Stripe-compatible pricing ID formatDeviceProperties,DeviceInput,DeviceUpdate, andDeviceInfoRoot Cause
The
snandprice_idfields in the OpenAPI spec had nopatternconstraint, allowing any string input including Chinese characters and other non-ASCII text. This is invalid because:price_1ABC2DEF)Changes
openapi.yaml: Addedpattern: ^[a-zA-Z0-9_-]+$to allsnandprice_idfield definitionsopenapi.json: Added"pattern": "^[a-zA-Z0-9_-]+$"to all correspondingsnandprice_idfield definitionsAffected schemas:
DevicePropertiessnDevicePropertiesprice_idDeviceInputsnDeviceUpdatesnDeviceUpdateprice_idDeviceInfosnTest Plan
snvalues containing Chinese characters (e.g.,{"sn": "测试设备"})snvalues (e.g.,{"sn": "SFVA78RABZ12345678"})price_idrejects Chinese characters (e.g.,{"price_id": "价格"})price_idaccepts valid Stripe IDs (e.g.,{"price_id": "price_1ABC2DEF"})Closes #3
Closes #4
🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes