Skip to content

fix: reject non-alphanumeric SN codes in POST /v1/devices #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Washio20 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix: reject non-alphanumeric SN codes in POST /v1/devices #10

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions openapi.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1384,7 +1384,8 @@
"schema": {
"type": "string",
"minLength": 1,
"maxLength": 256
"maxLength": 256,
"pattern": "^[a-zA-Z0-9_-]+$"
},
"description": "Device serial number",
"example": "SFVA78RABZ12345678"
Expand Down Expand Up @@ -7308,6 +7309,7 @@
"sn": {
"type": "string",
"nullable": true,
Copy link

Copilot AI Feb 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In JSON, the /v1/devices/sn/{sn} parameter enforces maxLength: 256, but the sn fields in request-body schemas (e.g., DeviceProperties / DeviceInput / DeviceUpdate) still lack minLength/maxLength. That means POST/PATCH can accept very long SN strings that can’t be used with the SN lookup endpoint and may increase validation/payload costs. Align the sn length constraints across schemas (e.g., minLength 1, maxLength 256).

Suggested change
"nullable": true,
"nullable": true,
"minLength": 1,
"maxLength": 256,

Copilot uses AI. Check for mistakes.
"pattern": "^[a-zA-Z0-9_-]+$",
"description": "Serial number of the device."
Comment on lines 7310 to 7313
Copy link

@coderabbitai coderabbitai bot Mar 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

SN length constraints are inconsistent between body and path validation.

/v1/devices/sn/{sn} restricts sn to 256 chars (Line 1387), but DeviceProperties.sn, DeviceInput.sn, and DeviceUpdate.sn have no maxLength. This can allow create/update inputs that later fail path validation when querying by SN.

💡 Proposed fix 
"sn": {
  "type": "string",
  "nullable": true,
+ "maxLength": 256,
  "pattern": "^[a-zA-Z0-9_-]+$",
  "description": "Serial number of the device."
}
"sn": {
  "type": "string",
+ "maxLength": 256,
  "pattern": "^[a-zA-Z0-9_-]+$",
  "description": "Serial number of the device. This field is required when creating a device."
}
"sn": {
  "type": "string",
  "nullable": true,
+ "maxLength": 256,
  "pattern": "^[a-zA-Z0-9_-]+$"
}

Also applies to: 7450-7453, 7473-7477

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@openapi.json` around lines 7310 - 7313, The schemas DeviceProperties.sn,
DeviceInput.sn, and DeviceUpdate.sn lack a maxLength constraint while the path
parameter /v1/devices/sn/{sn} enforces maxLength 256; add "maxLength": 256 to
each of those schema properties (and to the other duplicated schema occurrences
noted around the other ranges) so body validation matches the path parameter,
ensuring create/update payloads cannot exceed the path's 256-character limit.

},
"display_name": {
Expand Down Expand Up @@ -7447,6 +7449,7 @@
},
"sn": {
"type": "string",
"pattern": "^[a-zA-Z0-9_-]+$",
"description": "Serial number of the device. This field is required when creating a device."
}
}
Expand All @@ -7469,7 +7472,8 @@
},
"sn": {
"type": "string",
"nullable": true
"nullable": true,
"pattern": "^[a-zA-Z0-9_-]+$"
},
"display_name": {
"type": "string",
Expand Down Expand Up @@ -7500,6 +7504,7 @@
"properties": {
"sn": {
"type": "string",
"pattern": "^[a-zA-Z0-9_-]+$",
"description": "Device serial number",
"example": "SFVA78RABZ12345678"
},
Expand Down
5 changes: 5 additions & 0 deletions openapi.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1044,6 +1044,7 @@ paths:
type: string
minLength: 1
maxLength: 256
pattern: ^[a-zA-Z0-9_-]+$
description: Device serial number
example: SFVA78RABZ12345678
get:
Expand Down Expand Up @@ -5776,6 +5777,7 @@ components:
sn:
type: string
nullable: true
Copy link

Copilot AI Feb 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SN validation is now applied via pattern, but the request-body schemas don’t define minLength/maxLength for sn (while the /v1/devices/sn/{sn} path parameter enforces 1..256). This creates inconsistent constraints across endpoints and still allows arbitrarily large SN strings in POST/PATCH bodies. Consider adding consistent length limits (e.g., minLength 1 and maxLength 256) to all sn schema occurrences.

Suggested change
nullable: true
nullable: true
minLength: 1
maxLength: 256

Copilot uses AI. Check for mistakes.
pattern: ^[a-zA-Z0-9_-]+$
description: Serial number of the device.
display_name:
type: string
Expand Down Expand Up @@ -5940,6 +5942,7 @@ components:
'
sn:
type: string
pattern: ^[a-zA-Z0-9_-]+$
description: Serial number of the device. This field is required when creating
a device.
DeviceUpdate:
Expand All @@ -5962,6 +5965,7 @@ components:
sn:
type: string
nullable: true
pattern: ^[a-zA-Z0-9_-]+$
display_name:
type: string
nullable: true
Expand All @@ -5982,6 +5986,7 @@ components:
properties:
sn:
type: string
pattern: ^[a-zA-Z0-9_-]+$
description: Device serial number
example: SFVA78RABZ12345678
model_name:
Expand Down