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 _choices endpoints were deprecated in favor of incomplete alternative #4279

New Issue
Closed
opened 2025-12-29 18:34:23 +01:00 by adam · 6 comments
adam commented 2025-12-29 18:34:23 +01:00
Owner
Copy Link

Originally created by @ajknv on GitHub (Nov 16, 2020).

Environment

  • Python version: 3.6.8
  • NetBox version: 2.9.9

Steps to Reproduce

  1. Make an OPTIONS request via the API using a token for a user without write-permissions on the target model.
  2. Observe that no actual choices are returned in the response.
  3. Search the API/documentation for a functionally equivalent replacement for the old "_choices" endpoints, to no avail.
    (See also https://github.com/netbox-community/netbox/issues/5335)

Expected Behavior

The replacement for a deprecated capability should be functionally equivalent, or document the risk/rationale as to why some or all of the functionality can no longer be supported. However, the issue where the deprecation was tracked (https://github.com/netbox-community/netbox/issues/3416) seemed to assume -- erroneously -- that the OPTIONS queries were in fact functionally equivalent.

Observed Behavior

An API client using a token associated with a read-only user does not get valid choices data from an OPTIONS request, and in fact has no current means of querying for choices anymore. This is therefore a breaking event for existing code written before the deprecation (that seeks to follow security best practice of least-required-privilege). For example clients using pynetbox.choices() with certain user permissions now receive different/breaking responses with no viable alternative. This ought to be addressed as a regression bug in the interim to addressing https://github.com/netbox-community/netbox/issues/5352.

Originally created by @ajknv on GitHub (Nov 16, 2020). ### Environment * Python version: 3.6.8 * NetBox version: 2.9.9 ### Steps to Reproduce 1. Make an OPTIONS request via the API using a token for a user without write-permissions on the target model. 2. Observe that no actual choices are returned in the response. 3. Search the API/documentation for a functionally equivalent replacement for the old "_choices" endpoints, to no avail. (See also https://github.com/netbox-community/netbox/issues/5335) ### Expected Behavior The replacement for a deprecated capability should be functionally equivalent, or document the risk/rationale as to why some or all of the functionality can no longer be supported. However, the issue where the deprecation was tracked (https://github.com/netbox-community/netbox/issues/3416) seemed to assume -- erroneously -- that the OPTIONS queries were in fact functionally equivalent. ### Observed Behavior An API client using a token associated with a read-only user does not get valid choices data from an OPTIONS request, and in fact has no current means of querying for choices anymore. This is therefore a breaking event for existing code written before the deprecation (that seeks to follow security best practice of least-required-privilege). For example clients using pynetbox.choices() with certain user permissions now receive different/breaking responses with no viable alternative. This ought to be addressed as a regression bug in the interim to addressing https://github.com/netbox-community/netbox/issues/5352.
adam closed this issue 2025-12-29 18:34:23 +01:00
adam commented 2025-12-29 18:34:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2020):

As I explained in #5335, this needs to be re-written as a feature request, using the proper template.

@jeremystretch commented on GitHub (Nov 16, 2020): As [I explained](https://github.com/netbox-community/netbox/issues/5335#issuecomment-728132418) in #5335, this needs to be re-written as a feature request, using the [proper template](https://github.com/netbox-community/netbox/issues/new?template=feature_request.md).
adam commented 2025-12-29 18:34:24 +01:00
Author
Owner
Copy Link

@ajknv commented on GitHub (Nov 16, 2020):

Previously existing functionality was broken, how is recovering the regression in behavior a feature and not a bug? To put it another way, adding the OPTIONS capability was never a functionally equivalent substitution for the _choices endpoints in the first place.

@ajknv commented on GitHub (Nov 16, 2020): Previously existing functionality was broken, how is recovering the regression in behavior a feature and not a bug? To put it another way, adding the OPTIONS capability was never a functionally equivalent substitution for the _choices endpoints in the first place.
adam commented 2025-12-29 18:34:24 +01:00
Author
Owner
Copy Link

@ajknv commented on GitHub (Nov 16, 2020):

(If it really must be a feature request, then I would posit that the old _choices endpoints should be restored first in the interim. The feature request then becomes replacing them with something alternative that is preferred for some reason.)

@ajknv commented on GitHub (Nov 16, 2020): (If it really must be a feature request, then I would posit that the old _choices endpoints should be restored first in the interim. The feature request then becomes replacing them with something alternative that is preferred for some reason.)
adam commented 2025-12-29 18:34:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2020):

Previously existing functionality was broken, how is recovering the regression in behavior a feature and not a bug?

Nothing was broken: It was intentionally removed as described in #3416. Hence the need for a feature request citing a use case. If you don't turn this into a feature request, it will be marked as invalid and closed.

@jeremystretch commented on GitHub (Nov 16, 2020): > Previously existing functionality was broken, how is recovering the regression in behavior a feature and not a bug? Nothing was broken: It was intentionally removed as described in #3416. Hence the need for a feature request citing a use case. If you don't turn this into a feature request, it will be marked as invalid and closed.
adam commented 2025-12-29 18:34:24 +01:00
Author
Owner
Copy Link

@ajknv commented on GitHub (Nov 16, 2020):

Nothing was broken: It was intentionally removed as described in #3416.

I am aware of the deprecration, the problem is that it was apparently based on the claim that OPTIONS requests were a complete substitution for the capability of the _choices endpoints, which unfortunately is clearly not the case. So from a practical standpoint existing clients of the API certainly were broken as a consequence. Nonetheless I have filed the feature request, and revised the issue report here to instead more precisely characterize the regression bug aspect of the deprecation change.

@ajknv commented on GitHub (Nov 16, 2020): > Nothing was broken: It was intentionally removed as described in #3416. I am aware of the deprecration, the problem is that it was apparently based on the claim that OPTIONS requests were a complete substitution for the capability of the _choices endpoints, which unfortunately is clearly not the case. So from a practical standpoint existing clients of the API certainly were _broken_ as a consequence. Nonetheless I have filed the feature request, and revised the issue report here to instead more precisely characterize the regression bug aspect of the deprecation change.
adam commented 2025-12-29 18:34:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2020):

Submitted as a FR in #5352.

@jeremystretch commented on GitHub (Nov 16, 2020): Submitted as a FR in #5352.
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
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#4279
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?