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

API returns all objects instead of an error #11220

New Issue
Closed
opened 2025-12-29 21:42:05 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:42:05 +01:00
Owner
Copy Link

Originally created by @m0nkeyc0de on GitHub (May 27, 2025).

Deployment Type

Self-hosted

NetBox Version

v4.3.1

Python Version

3.10

Steps to Reproduce

Call the GET API with a non-existing field (typo error, breaking change in a NetBox Django Model, ...).

This issue doesn't rely on specific data and can be reproduced on the demo instance:
https://demo.netbox.dev/api/dcim/devices/?sadnjashdjahs=100

Expected Behavior

An error should be returned as the field sadnjashdjahs doesn't exist in the list of possible fields.

Observed Behavior

The observed behavior is fail silently and do otherwise (returning the entire database table), which defeats the whole purpose of NetBox : beeing a reliable source of truth.

Originally created by @m0nkeyc0de on GitHub (May 27, 2025). ### Deployment Type Self-hosted ### NetBox Version v4.3.1 ### Python Version 3.10 ### Steps to Reproduce Call the GET API with a non-existing field (typo error, breaking change in a NetBox Django Model, ...). This issue doesn't rely on specific data and can be reproduced on the demo instance: `https://demo.netbox.dev/api/dcim/devices/?sadnjashdjahs=100` ### Expected Behavior An error should be returned as the field `sadnjashdjahs` doesn't exist in the [list of possible fields](https://demo.netbox.dev/api/schema/swagger-ui/#/dcim/dcim_devices_list). ### Observed Behavior The observed behavior is `fail silently and do otherwise` (returning the entire database table), which defeats the whole purpose of NetBox : beeing a reliable source of truth.
adam added the netbox label 2025-12-29 21:42:05 +01:00
adam closed this issue 2025-12-29 21:42:05 +01:00
adam commented 2025-12-29 21:42:06 +01:00
Author
Owner
Copy Link

@m0nkeyc0de commented on GitHub (May 27, 2025):

This API behavior seems to be troubling people for a long while : https://github.com/netbox-community/netbox/discussions/7907

@m0nkeyc0de commented on GitHub (May 27, 2025): This API behavior seems to be troubling people for a long while : https://github.com/netbox-community/netbox/discussions/7907
adam commented 2025-12-29 21:42:07 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 27, 2025):

This is intended behavior. Invalid filters are ignored.

@jeremystretch commented on GitHub (May 27, 2025): This is intended behavior. Invalid filters are ignored.
adam commented 2025-12-29 21:42:07 +01:00
Author
Owner
Copy Link

@peterbaumert commented on GitHub (May 27, 2025):

So this should be reopened as feature request then? I mean it's not really a good practice to ignore errors i guess.

@peterbaumert commented on GitHub (May 27, 2025): So this should be reopened as feature request then? I mean it's not really a good practice to ignore errors i guess.
adam commented 2025-12-29 21:42:07 +01:00
Author
Owner
Copy Link

@m0nkeyc0de commented on GitHub (May 28, 2025):

@peterbaumert I also don't understand this counterintuitive design decision and I can't afford to have my scripts doing unexpected stuff on my network because my source of truth is suddenly silently lying to me. This is an absolute deal breaker.

I'm implementing this validation in the Pynetbox library and will submit a PR soon (https://github.com/netbox-community/pynetbox/issues/693). It is the best way to handle this problem until this intended behavior is reconsidered by the project owners.

@m0nkeyc0de commented on GitHub (May 28, 2025): @peterbaumert I also don't understand this counterintuitive design decision and I can't afford to have my scripts doing unexpected stuff on my network because my _source of truth_ is suddenly silently lying to me. This is an absolute deal breaker. I'm implementing this validation in the Pynetbox library and will submit a PR soon (https://github.com/netbox-community/pynetbox/issues/693). It is the best way to handle this problem until this _intended behavior_ is reconsidered by the project owners.
adam commented 2025-12-29 21:42:07 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 28, 2025):

I also don't understand this counterintuitive design decision and I can't afford to have my scripts doing unexpected stuff on my network because my source of truth is suddenly silently lying to me.

NetBox is not "lying to you" when you use an invalid filter name. It is simply ignoring an unrecognized parameter, as it should. This is a very well understood convention in web applications.

Consider the implications of what you're proposing for a moment. Not all query parameters are filters: They can be used for many different functions, including those introduced by third party plugins and middleware over which NetBox itself has no control. Raising an error on the presence of any query parameter not recognized by NetBox is simply not feasible.

@jeremystretch commented on GitHub (May 28, 2025): > I also don't understand this counterintuitive design decision and I can't afford to have my scripts doing unexpected stuff on my network because my source of truth is suddenly silently lying to me. NetBox is not "lying to you" when you use an invalid filter name. It is simply ignoring an unrecognized parameter, as it should. This is a very well understood convention in web applications. Consider the implications of what you're proposing for a moment. Not all query parameters are filters: They can be used for many different functions, including those introduced by third party plugins and middleware over which NetBox itself has no control. Raising an error on the presence of any query parameter not recognized by NetBox is simply not feasible.
adam commented 2025-12-29 21:42:07 +01:00
Author
Owner
Copy Link

@m0nkeyc0de commented on GitHub (Jun 2, 2025):

Thanks for the explanation. I understand that modifying this behavior would break a lot of stuff.

I'm looking to have this check optionnally done on pynetbox side (https://github.com/netbox-community/pynetbox/issues/695) , which seems far less risky considering the situation.

Does the provided OpenAPI specification (https://demo.netbox.dev/api/schema/) contain all the possible filter expressions for a Netbox deployment without plugins ?

Would it be feasible to have at least an indication that no filters were applied in the API response ? Doing this would help to differenciate between a query that returns 4321 results because the valid filter matches all the objects and a query that also returns 4321 objects because no filters were applied.

@m0nkeyc0de commented on GitHub (Jun 2, 2025): Thanks for the explanation. I understand that modifying this behavior would break a lot of stuff. I'm looking to have this check optionnally done on `pynetbox` side (https://github.com/netbox-community/pynetbox/issues/695) , which seems far less risky considering the situation. Does the provided OpenAPI specification (https://demo.netbox.dev/api/schema/) contain all the possible filter expressions for a Netbox deployment without plugins ? Would it be feasible to have at least an indication that no filters were applied in the API response ? Doing this would help to differenciate between a query that returns 4321 results because the valid filter matches all the objects and a query that also returns 4321 objects because no filters were applied.
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 netbox
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#11220
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?