fix: validate SN field rejects non-alphanumeric characters#14
Open
Washio20 wants to merge 1 commit intostayforge:mainfrom
Open
fix: validate SN field rejects non-alphanumeric characters#14Washio20 wants to merge 1 commit intostayforge:mainfrom
Washio20 wants to merge 1 commit intostayforge:mainfrom
Conversation
Add regex pattern validation (^[a-zA-Z0-9]+$) to the SN field across
all device schemas (DeviceProperties, DeviceInput, DeviceUpdate,
DeviceInfo) and the /v1/devices/sn/{sn} path parameter. This ensures
serial numbers only contain ASCII alphanumeric characters, rejecting
Unicode characters like Chinese.
Closes stayforge#3
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughOpenAPI schema definitions were updated to enforce alphanumeric pattern validation on device serial number (sn) fields across multiple schema objects (DeviceProperties, DeviceUpdate, DeviceInfo, DeviceInput) and the corresponding path parameter, with minLength 1 and maxLength 256 constraints applied. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 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 |
![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)
1040-1049:⚠️ Potential issue | 🟡 MinorDocument the
400response for invalidsnpath parameter format.The
snpath parameter now carries apatternconstraint, so an invalid SN (e.g./v1/devices/sn/SN是2025) will produce a validation error. However, theGetDeviceSNoperation documents no400response — unlike every other endpoint with a patterned path parameter (e.g.,OrganizationIdPathwhich consistently includes400: invalid_path_parameter).📝 Proposed fix — add 400 response to `GetDeviceSN`
operationId: GetDeviceSN tags: - Devices security: - ApiKeyAuth: [] parameters: - $ref: '#/components/parameters/ApiKeyHeader' responses: '200': description: Device information ... + '400': + description: 'Bad request - Invalid path parameter format. + + Error codes: `invalid_path_parameter` + + ' + content: + application/json: + schema: + $ref: '#/components/schemas/Error' + examples: + invalid_path_parameter: + value: + code: invalid_path_parameter + message: sn must match pattern ^[a-zA-Z0-9]+$ '401':Also applies to: 1050-1142
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@openapi.yaml` around lines 1040 - 1049, The GetDeviceSN operation (parameter name: sn) now has a pattern constraint but lacks a documented 400 response; add a 400 response entry to the GetDeviceSN operation describing "invalid_path_parameter" (matching the same schema/description used by OrganizationIdPath and other patterned endpoints) so requests with invalid SN formats return the standardized 400: invalid_path_parameter response; ensure the response reference/name and any $ref to the shared error schema are consistent with other endpoints' 400 responses.
🧹 Nitpick comments (2)
openapi.json (1)
1381-1389: Document invalid SN path-parameter errors for this endpoint.With the new
pattern/length validation onsn, consider adding a400 invalid_path_parameterresponse (and example) for/v1/devices/sn/{sn}to keep error docs consistent with other endpoints.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@openapi.json` around lines 1381 - 1389, Add a 400 "invalid_path_parameter" response for the endpoint /v1/devices/sn/{sn} to document validation failures for the path parameter "sn" (which now has minLength, maxLength and pattern constraints); update openapi.json to include a "400" response object keyed with "invalid_path_parameter" (or include that as the error code in the response body schema) and provide an example body showing the validation error for "sn" (e.g., message indicating pattern/length violation), ensuring the response schema matches the project's existing error response format used by other endpoints.openapi.yaml (1)
5969-5974:DeviceUpdate.snis missing adescriptionfield.
DeviceProperties.snandDeviceInput.snboth carry a description, but theDeviceUpdate.snoverride omits it. While most doc generators will fall back to the inherited description, explicitly including it keeps all three definitions consistent.✏️ Proposed fix
sn: type: string nullable: true + description: Serial number of the device. minLength: 1 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.yaml` around lines 5969 - 5974, DeviceUpdate.sn is missing a description; add the same description used on DeviceProperties.sn and DeviceInput.sn to the DeviceUpdate.sn schema so all three definitions are explicit and consistent—locate the DeviceUpdate object and add a description field alongside type/nullable/minLength/maxLength/pattern for the sn property (matching the description text from DeviceProperties.sn / DeviceInput.sn).
🤖 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 1040-1049: The GetDeviceSN operation (parameter name: sn) now has
a pattern constraint but lacks a documented 400 response; add a 400 response
entry to the GetDeviceSN operation describing "invalid_path_parameter" (matching
the same schema/description used by OrganizationIdPath and other patterned
endpoints) so requests with invalid SN formats return the standardized 400:
invalid_path_parameter response; ensure the response reference/name and any $ref
to the shared error schema are consistent with other endpoints' 400 responses.
---
Nitpick comments:
In `@openapi.json`:
- Around line 1381-1389: Add a 400 "invalid_path_parameter" response for the
endpoint /v1/devices/sn/{sn} to document validation failures for the path
parameter "sn" (which now has minLength, maxLength and pattern constraints);
update openapi.json to include a "400" response object keyed with
"invalid_path_parameter" (or include that as the error code in the response body
schema) and provide an example body showing the validation error for "sn" (e.g.,
message indicating pattern/length violation), ensuring the response schema
matches the project's existing error response format used by other endpoints.
In `@openapi.yaml`:
- Around line 5969-5974: DeviceUpdate.sn is missing a description; add the same
description used on DeviceProperties.sn and DeviceInput.sn to the
DeviceUpdate.sn schema so all three definitions are explicit and
consistent—locate the DeviceUpdate object and add a description field alongside
type/nullable/minLength/maxLength/pattern for the sn property (matching the
description text from DeviceProperties.sn / DeviceInput.sn).
There was a problem hiding this comment.
Pull request overview
This pull request adds regex pattern validation to the sn (serial number) field across all device-related schemas in the OpenAPI specification to prevent non-alphanumeric characters (such as Chinese characters) from being accepted. The changes introduce the pattern ^[a-zA-Z0-9]+$ along with minLength: 1 and maxLength: 256 constraints.
Changes:
- Added alphanumeric-only validation pattern to serial number fields across four device schemas (DeviceProperties, DeviceInput, DeviceUpdate, DeviceInfo)
- Added pattern validation to the
/v1/devices/sn/{sn}path parameter - Applied consistent length constraints (1-256 characters) where missing
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 ^[a-zA-Z0-9]+$ and length constraints to sn field in DeviceProperties, DeviceInput, DeviceUpdate, DeviceInfo schemas and path parameter |
| openapi.json | Applied identical validation changes to JSON format specification for consistency |
Comments suppressed due to low confidence (14)
openapi.json:7455
- The pattern
^[a-zA-Z0-9]+$only allows alphanumeric characters and will reject serial numbers containing hyphens, underscores, or other special characters that are commonly used in real-world serial numbers (e.g., "ABC-123-XYZ" or "SN_2025_001"). If the goal is only to prevent Unicode characters like Chinese characters while still supporting standard punctuation used in serial numbers, consider using a more permissive pattern such as^[a-zA-Z0-9\-_]+$or similar. Verify that this strict pattern aligns with the actual serial number formats used by your devices.
"pattern": "^[a-zA-Z0-9]+$",
openapi.json:7480
- The pattern
^[a-zA-Z0-9]+$only allows alphanumeric characters and will reject serial numbers containing hyphens, underscores, or other special characters that are commonly used in real-world serial numbers (e.g., "ABC-123-XYZ" or "SN_2025_001"). If the goal is only to prevent Unicode characters like Chinese characters while still supporting standard punctuation used in serial numbers, consider using a more permissive pattern such as^[a-zA-Z0-9\-_]+$or similar. Verify that this strict pattern aligns with the actual serial number formats used by your devices.
"pattern": "^[a-zA-Z0-9]+$",
openapi.json:7515
- The pattern
^[a-zA-Z0-9]+$only allows alphanumeric characters and will reject serial numbers containing hyphens, underscores, or other special characters that are commonly used in real-world serial numbers (e.g., "ABC-123-XYZ" or "SN_2025_001"). If the goal is only to prevent Unicode characters like Chinese characters while still supporting standard punctuation used in serial numbers, consider using a more permissive pattern such as^[a-zA-Z0-9\-_]+$or similar. Verify that this strict pattern aligns with the actual serial number formats used by your devices.
"pattern": "^[a-zA-Z0-9]+$",
openapi.json:7482
- The combination of
nullable: truewithminLength: 1creates a validation conflict. When the field is null, the minLength constraint should not apply, but some OpenAPI validators may incorrectly reject null values. Consider whether this field should truly be nullable, or if it should always be required when present. If it must be nullable, document that the constraints only apply to non-null values.
"sn": {
"type": "string",
"nullable": true,
"pattern": "^[a-zA-Z0-9]+$",
"minLength": 1,
"maxLength": 256
openapi.yaml:5783
- The pattern
^[a-zA-Z0-9]+$only allows alphanumeric characters and will reject serial numbers containing hyphens, underscores, or other special characters that are commonly used in real-world serial numbers (e.g., "ABC-123-XYZ" or "SN_2025_001"). If the goal is only to prevent Unicode characters like Chinese characters while still supporting standard punctuation used in serial numbers, consider using a more permissive pattern such as^[a-zA-Z0-9\-_]+$or similar. Verify that this strict pattern aligns with the actual serial number formats used by your devices.
pattern: ^[a-zA-Z0-9]+$
openapi.yaml:5999
- The pattern
^[a-zA-Z0-9]+$only allows alphanumeric characters and will reject serial numbers containing hyphens, underscores, or other special characters that are commonly used in real-world serial numbers (e.g., "ABC-123-XYZ" or "SN_2025_001"). If the goal is only to prevent Unicode characters like Chinese characters while still supporting standard punctuation used in serial numbers, consider using a more permissive pattern such as^[a-zA-Z0-9\-_]+$or similar. Verify that this strict pattern aligns with the actual serial number formats used by your devices.
pattern: ^[a-zA-Z0-9]+$
openapi.yaml:1047
- The pattern
^[a-zA-Z0-9]+$only allows alphanumeric characters and will reject serial numbers containing hyphens, underscores, or other special characters that are commonly used in real-world serial numbers (e.g., "ABC-123-XYZ" or "SN_2025_001"). If the goal is only to prevent Unicode characters like Chinese characters while still supporting standard punctuation used in serial numbers, consider using a more permissive pattern such as^[a-zA-Z0-9\-_]+$or similar. Verify that this strict pattern aligns with the actual serial number formats used by your devices.
pattern: ^[a-zA-Z0-9]+$
openapi.json:7313
- The pattern
^[a-zA-Z0-9]+$only allows alphanumeric characters and will reject serial numbers containing hyphens, underscores, or other special characters that are commonly used in real-world serial numbers (e.g., "ABC-123-XYZ" or "SN_2025_001"). If the goal is only to prevent Unicode characters like Chinese characters while still supporting standard punctuation used in serial numbers, consider using a more permissive pattern such as^[a-zA-Z0-9\-_]+$or similar. Verify that this strict pattern aligns with the actual serial number formats used by your devices.
"pattern": "^[a-zA-Z0-9]+$",
openapi.json:1388
- The pattern
^[a-zA-Z0-9]+$only allows alphanumeric characters and will reject serial numbers containing hyphens, underscores, or other special characters that are commonly used in real-world serial numbers (e.g., "ABC-123-XYZ" or "SN_2025_001"). If the goal is only to prevent Unicode characters like Chinese characters while still supporting standard punctuation used in serial numbers, consider using a more permissive pattern such as^[a-zA-Z0-9\-_]+$or similar. Verify that this strict pattern aligns with the actual serial number formats used by your devices.
"pattern": "^[a-zA-Z0-9]+$"
openapi.yaml:5783
- The combination of
nullable: truewithminLength: 1creates a validation conflict. When the field is null, the minLength constraint should not apply, but some OpenAPI validators may incorrectly reject null values. Consider whether this field should truly be nullable, or if it should always be required when present. If it must be nullable, document that the constraints only apply to non-null values.
sn:
type: string
nullable: true
description: Serial number of the device.
minLength: 1
maxLength: 256
pattern: ^[a-zA-Z0-9]+$
openapi.yaml:5974
- The combination of
nullable: truewithminLength: 1creates a validation conflict. When the field is null, the minLength constraint should not apply, but some OpenAPI validators may incorrectly reject null values. Consider whether this field should truly be nullable, or if it should always be required when present. If it must be nullable, document that the constraints only apply to non-null values.
sn:
type: string
nullable: true
minLength: 1
maxLength: 256
pattern: ^[a-zA-Z0-9]+$
openapi.json:7315
- The combination of
nullable: truewithminLength: 1creates a validation conflict. When the field is null, the minLength constraint should not apply, but some OpenAPI validators may incorrectly reject null values. Consider whether this field should truly be nullable, or if it should always be required when present. If it must be nullable, document that the constraints only apply to non-null values.
"sn": {
"type": "string",
"nullable": true,
"description": "Serial number of the device.",
"pattern": "^[a-zA-Z0-9]+$",
"minLength": 1,
"maxLength": 256
openapi.yaml:5951
- The pattern
^[a-zA-Z0-9]+$only allows alphanumeric characters and will reject serial numbers containing hyphens, underscores, or other special characters that are commonly used in real-world serial numbers (e.g., "ABC-123-XYZ" or "SN_2025_001"). If the goal is only to prevent Unicode characters like Chinese characters while still supporting standard punctuation used in serial numbers, consider using a more permissive pattern such as^[a-zA-Z0-9\-_]+$or similar. Verify that this strict pattern aligns with the actual serial number formats used by your devices.
pattern: ^[a-zA-Z0-9]+$
openapi.yaml:5974
- The pattern
^[a-zA-Z0-9]+$only allows alphanumeric characters and will reject serial numbers containing hyphens, underscores, or other special characters that are commonly used in real-world serial numbers (e.g., "ABC-123-XYZ" or "SN_2025_001"). If the goal is only to prevent Unicode characters like Chinese characters while still supporting standard punctuation used in serial numbers, consider using a more permissive pattern such as^[a-zA-Z0-9\-_]+$or similar. Verify that this strict pattern aligns with the actual serial number formats used by your devices.
pattern: ^[a-zA-Z0-9]+$
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
^[a-zA-Z0-9]+$) to thesnfield across all device schemasminLength/maxLengthconstraints where missing/v1/devices/sn/{sn}path parameterRoot Cause
The SN field had no character set validation, allowing any Unicode characters (including Chinese characters) to be accepted as serial numbers.
Changes
DeviceProperties.sn: Addedpattern,minLength,maxLengthDeviceInput.sn: Addedpattern,minLength,maxLengthDeviceUpdate.sn: Addedpattern,minLength,maxLengthDeviceInfo.sn: Addedpattern,minLength,maxLengthsnin/v1/devices/sn/{sn}: Addedpatternopenapi.yamlandopenapi.jsonTesting
SN202501是2002) will now be rejected with a 422 errorSFVA78RABZ12345678) continue to workCloses #3
🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes