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

Enable field for API tokens #11850

New Issue
Closed
opened 2025-12-29 21:50:40 +01:00 by adam · 8 comments
adam commented 2025-12-29 21:50:40 +01:00
Owner
Copy Link

Originally created by @mr1716 on GitHub (Nov 19, 2025).

Originally assigned to: @pheus on GitHub.

NetBox version

v4.4.6

Feature type

New functionality

Proposed functionality

Have a button that users would be able to click which would enable and disable API Tokens.

At the time that the users create and edit the individual API Tokens, there would either be an Enable checkbox that checked means enabled this unchecked means disabled or a status drop-down that users can change.

Use case

If an API Token needs to be disabled or re-enabled, the only way to do that would be to change the Expiration Date or restrict the IPs. It’s less than ideal to be changing those values to simply enable or disable the tokens.

Database changes

A new field as either Status of either Enabled or Disabled or enabled: True for the API to do the comparison when authentication and use of an API Token is done. The idea being that if Enabled is set to True or Status is set to enabled, it would allow authentication. And this value would be able to be set by administrators at time of creation as well as part of normal work. Moreover, the value could be set to False or disabled when the Expiration Date passes.

External dependencies

Unsure.

Sorry if this is not useful, just thought it may be something that may help users with administering the tool

Originally created by @mr1716 on GitHub (Nov 19, 2025). Originally assigned to: @pheus on GitHub. ### NetBox version v4.4.6 ### Feature type New functionality ### Proposed functionality Have a button that users would be able to click which would enable and disable API Tokens. At the time that the users create and edit the individual API Tokens, there would either be an Enable checkbox that checked means enabled this unchecked means disabled or a status drop-down that users can change. ### Use case If an API Token needs to be disabled or re-enabled, the only way to do that would be to change the Expiration Date or restrict the IPs. It’s less than ideal to be changing those values to simply enable or disable the tokens. ### Database changes A new field as either Status of either Enabled or Disabled or enabled: True for the API to do the comparison when authentication and use of an API Token is done. The idea being that if Enabled is set to True or Status is set to enabled, it would allow authentication. And this value would be able to be set by administrators at time of creation as well as part of normal work. Moreover, the value could be set to False or disabled when the Expiration Date passes. ### External dependencies Unsure. Sorry if this is not useful, just thought it may be something that may help users with administering the tool
adam added the status: acceptedtype: featurenetboxcomplexity: low labels 2025-12-29 21:50:40 +01:00
adam closed this issue 2025-12-29 21:50:40 +01:00
adam commented 2025-12-29 21:50:40 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Nov 19, 2025):

I think this is potentially useful, but as it stands, the FR doesn't seem to have enough detail to be actionable. If we need to persist a user's choice to enable/disable an API token, then database changes are definitely required. Similarly, this FR glosses over the expected behaviors (both in the Token edit view and in the API auth boundary) and the necessary changes to the related auth mechanism (and potentially other areas).

Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

@jnovinger commented on GitHub (Nov 19, 2025): I think this is potentially useful, but as it stands, the FR doesn't seem to have enough detail to be actionable. If we need to persist a user's choice to enable/disable an API token, then database changes are definitely required. Similarly, this FR glosses over the expected behaviors (both in the Token edit view and in the API auth boundary) and the necessary changes to the related auth mechanism (and potentially other areas). Per our [contributing guide](https://github.com/netbox-community/netbox/blob/main/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.
adam commented 2025-12-29 21:50:41 +01:00
Author
Owner
Copy Link

@mr1716 commented on GitHub (Nov 19, 2025):

@jnovinger just made some changes and will make some additional changes later. May have missed a few things, but will edit later

@mr1716 commented on GitHub (Nov 19, 2025): @jnovinger just made some changes and will make some additional changes later. May have missed a few things, but will edit later
adam commented 2025-12-29 21:50:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 20, 2025):

It sounds like what you want is to add an "enabled" boolean field on the Token model, as a control over whether the token can be used. This would present in the UI as a checkbox under the individual and bulk edit forms, rather than a button elsewhere. Does that capture your use case?

@jeremystretch commented on GitHub (Nov 20, 2025): It sounds like what you want is to add an "enabled" boolean field on the Token model, as a control over whether the token can be used. This would present in the UI as a checkbox under the individual and bulk edit forms, rather than a button elsewhere. Does that capture your use case?
adam commented 2025-12-29 21:50:41 +01:00
Author
Owner
Copy Link

@mr1716 commented on GitHub (Nov 20, 2025):

@jeremystretch, the idea is to have a way to ensure that there’s an easy way to enable and disable API Tokens. And the way Im proposing is the method you’re describing since I think there are other Netbox features that behave the same way in terms of enabling via the UI

@mr1716 commented on GitHub (Nov 20, 2025): @jeremystretch, the idea is to have a way to ensure that there’s an easy way to enable and disable API Tokens. And the way Im proposing is the method you’re describing since I think there are other Netbox features that behave the same way in terms of enabling via the UI
adam commented 2025-12-29 21:50:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 20, 2025):

Opening this for v4.5. (Please submit any PRs to the feature branch.) Also, the default value for the enabled field should be true.

@jeremystretch commented on GitHub (Nov 20, 2025): Opening this for v4.5. (Please submit any PRs to the `feature` branch.) Also, the default value for the `enabled` field should be true.
adam commented 2025-12-29 21:50:42 +01:00
Author
Owner
Copy Link

@mr1716 commented on GitHub (Nov 20, 2025):

@jeremystretch thanks. May not have capacity for this at this time as Im busy

@mr1716 commented on GitHub (Nov 20, 2025): @jeremystretch thanks. May not have capacity for this at this time as Im busy
adam commented 2025-12-29 21:50:42 +01:00
Author
Owner
Copy Link

@pheus commented on GitHub (Nov 21, 2025):

I’d be happy to work on this enhancement. Could you please assign the issue to me? Thank you!

Note: I’m planning to wait for main to be merged into feature so I can pick up the changes from #20823 and help reduce potential merge conflicts.

@pheus commented on GitHub (Nov 21, 2025): I’d be happy to work on this enhancement. Could you please assign the issue to me? Thank you! _Note_: I’m planning to wait for `main` to be merged into `feature` so I can pick up the changes from #20823 and help reduce potential merge conflicts.
adam commented 2025-12-29 21:50:42 +01:00
Author
Owner
Copy Link

@mr1716 commented on GitHub (Nov 22, 2025):

Just realized that this does have security benefits as well. Not that it fixes a security vulnerability, but does benefit security around token administration

@mr1716 commented on GitHub (Nov 22, 2025): Just realized that this does have security benefits as well. Not that it fixes a security vulnerability, but does benefit security around token administration
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 complexity: low netbox status: accepted 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#11850
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?