starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Regex validation for JSON custom fields #6410

New Issue
Closed
opened 2025-12-29 19:40:22 +01:00 by adam · 6 comments
adam commented 2025-12-29 19:40:22 +01:00
Owner
Copy Link

Originally created by @AndMrzv on GitHub (Apr 27, 2022).

NetBox version

v3.1.10

Feature type

New functionality

Proposed functionality

Regex validation for custom fields of JSON type with regex set in the "Validation" block of custom field settings.

When I try it now it says "Regular expression validation is supported only for text and URL fields".

Use case

Json fields are very nice to have, I've been converting to them all json data previously stored in Netbox as text strings for external systems and scripts to parse exactly as it was meant in https://github.com/netbox-community/netbox/issues/7452
I was hoping that with json type users will now be unable to put something non-json in such fields (this kills whatever is dependent on proper data format) but you can actually put anything in a json field as long as you frame it with quotes so it could be regarded as string and not checked for being a proper json.

A very simple regex demanding field's value to be framed with curly braces would be enough to counter this (yes, user can see an error message and put a single string inside of braces but at least this would require him to think twice drastically reducing mistakes).

Even better if I have very specific data in the field, let's say I use something like
{"numeric_parameter1": 123; "numeric_parameter2": 456, "codeword": "this"}
for racks, I could compose a regex allowing changing only values and according to my rules (i.e. [0-9]{1-4}, can't be negative, etc) providing superb data integrity with unseen ease of use.

Yes, I can solve this with extra custom validators but using a native already existing feature would be cool.

Database changes

No response

External dependencies

No response

Originally created by @AndMrzv on GitHub (Apr 27, 2022). ### NetBox version v3.1.10 ### Feature type New functionality ### Proposed functionality Regex validation for custom fields of JSON type with regex set in the "Validation" block of custom field settings. When I try it now it says "Regular expression validation is supported only for text and URL fields". ### Use case Json fields are very nice to have, I've been converting to them all json data previously stored in Netbox as text strings for external systems and scripts to parse exactly as it was meant in https://github.com/netbox-community/netbox/issues/7452 I was hoping that with json type users will now be unable to put something non-json in such fields (this kills whatever is dependent on proper data format) but you can actually put anything in a json field as long as you frame it with quotes so it could be regarded as string and not checked for being a proper json. A very simple regex demanding field's value to be framed with curly braces would be enough to counter this (yes, user can see an error message and put a single string inside of braces but at least this would require him to think twice drastically reducing mistakes). Even better if I have very specific data in the field, let's say I use something like {"numeric_parameter1": 123; "numeric_parameter2": 456, "codeword": "this"} for racks, I could compose a regex allowing changing only values and according to my rules (i.e. [0-9]{1-4}, can't be negative, etc) providing superb data integrity with unseen ease of use. Yes, I can solve this with extra custom validators but using a native already existing feature would be cool. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurepending closure labels 2025-12-29 19:40:22 +01:00
adam closed this issue 2025-12-29 19:40:22 +01:00
adam commented 2025-12-29 19:40:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 27, 2022):

It sounds like you're falling into the trap of wanting to use regular expressions to validate arbitrary data structures. Frankly, it's just never a good idea.

Yes, I can solve this with extra custom validators but using a native already existing feature would be cool.

It sounds cool until you're tasked with modifying a 200-character blob of regex which tries to validate a JSON object. A custom validator is going to work much better for this in pretty much every regard.

@jeremystretch commented on GitHub (Apr 27, 2022): It sounds like you're falling into the trap of wanting to use regular expressions to validate arbitrary data structures. Frankly, it's just _never_ a good idea. > Yes, I can solve this with extra custom validators but using a native already existing feature would be cool. It sounds cool until you're tasked with modifying a 200-character blob of regex which tries to validate a JSON object. A custom validator is going to work _much_ better for this in pretty much every regard.
adam commented 2025-12-29 19:40:23 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Apr 28, 2022):

What about instead of regex, an option is added to specify a JSON Schema for validation? I know that is something I was playing around with implementing as part of a custom validator, but seems like it could be useful to implement natively.

@sleepinggenius2 commented on GitHub (Apr 28, 2022): What about instead of regex, an option is added to specify a JSON Schema for validation? I know that is something I was playing around with implementing as part of a custom validator, but seems like it could be useful to implement natively.
adam commented 2025-12-29 19:40:23 +01:00
Author
Owner
Copy Link

@AndMrzv commented on GitHub (May 16, 2022):

It sounds like you're falling into the trap of wanting to use regular expressions to validate arbitrary data structures. Frankly, it's just never a good idea.

Yes, I can solve this with extra custom validators but using a native already existing feature would be cool.

It sounds cool until you're tasked with modifying a 200-character blob of regex which tries to validate a JSON object. A custom validator is going to work much better for this in pretty much every regard.

Okay, I can see the logic here. Though for me personally it is much more convenient and fast to work on 200-character regex everybody can see and be done with it rather than edit the my-validator.py, submit it, wait weeks for it's code to be reviewed and rolled into production and so on, I get that this process may be different for others.

Originally I didn't even need schema, simply not letting users to put a quoted string into a json field would be good enough.
Coming up with the validator.

@AndMrzv commented on GitHub (May 16, 2022): > It sounds like you're falling into the trap of wanting to use regular expressions to validate arbitrary data structures. Frankly, it's just _never_ a good idea. > > > Yes, I can solve this with extra custom validators but using a native already existing feature would be cool. > > It sounds cool until you're tasked with modifying a 200-character blob of regex which tries to validate a JSON object. A custom validator is going to work _much_ better for this in pretty much every regard. Okay, I can see the logic here. Though for me personally it is much more convenient and fast to work on 200-character regex everybody can see and be done with it rather than edit the my-validator.py, submit it, wait weeks for it's code to be reviewed and rolled into production and so on, I get that this process may be different for others. Originally I didn't even need schema, simply not letting users to put a quoted string into a json field would be good enough. Coming up with the validator.
adam commented 2025-12-29 19:40:23 +01:00
Author
Owner
Copy Link

@AndMrzv commented on GitHub (May 16, 2022):

Oh, soon I will be able to hide json fields from people or make them RO with https://github.com/netbox-community/netbox/issues/8560 and https://github.com/netbox-community/netbox/issues/9166 leaving only scripts which are never wrong to populate them.

@AndMrzv commented on GitHub (May 16, 2022): Oh, soon I will be able to hide json fields from people or make them RO with https://github.com/netbox-community/netbox/issues/8560 and https://github.com/netbox-community/netbox/issues/9166 leaving only scripts which are never wrong to populate them.
adam commented 2025-12-29 19:40:23 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 16, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jul 16, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:40:23 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 15, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Aug 15, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#6410
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?