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

application logs missing failed actions #1507

New Issue
Closed
opened 2025-12-29 16:32:33 +01:00 by adam · 8 comments
adam commented 2025-12-29 16:32:33 +01:00
Owner
Copy Link

Originally created by @tduehr on GitHub (Jan 24, 2018).

Issue type

[ ] Feature request
[X] Bug report
[ ] Documentation

Environment

  • Python version: 3.5.2
  • NetBox version: 2.2.8

Description

The console/file log output of Netbox is limited to authentication events.

I'm currently trying to debug the API as used by NetboxClientRuby. I'm getting 403 errors where I don't think I should be when creating objects (the API token has full write privileges and my user can create objects in the web UI fine). Looking at the logs in /var/log/supervisor, all I see are my authentication events. Further, turning the logging up to DEBUG does not change the output.

403 Forbidden ({"detail"=>"You do not have permission to perform this action."})

I expect DEBUG level logging to include errors in object creation for any reason. Especially, 403s which should likely show up at INFO if not all the way up at ERROR.

Originally created by @tduehr on GitHub (Jan 24, 2018). ### Issue type [ ] Feature request <!-- An enhancement of existing functionality --> [X] Bug report <!-- Unexpected or erroneous behavior --> [ ] Documentation <!-- A modification to the documentation --> ### Environment * Python version: 3.5.2 * NetBox version: 2.2.8 ### Description The console/file log output of Netbox is limited to authentication events. I'm currently trying to debug the API as used by NetboxClientRuby. I'm getting 403 errors where I don't think I should be when creating objects (the API token has full write privileges and my user can create objects in the web UI fine). Looking at the logs in `/var/log/supervisor`, all I see are my authentication events. Further, turning the logging up to `DEBUG` does not change the output. `403 Forbidden ({"detail"=>"You do not have permission to perform this action."})` I expect `DEBUG` level logging to include errors in object creation for any reason. Especially, 403s which should likely show up at `INFO` if not all the way up at `ERROR`.
adam closed this issue 2025-12-29 16:32:33 +01:00
adam commented 2025-12-29 16:32:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 30, 2018):

Authentication errors are just that: errors. There's nothing else to log because as soon as authentication fails, the request is aborted. What are you asking be changed?

@jeremystretch commented on GitHub (Jan 30, 2018): Authentication errors are just that: errors. There's nothing else to log because as soon as authentication fails, the request is aborted. What are you asking be changed?
adam commented 2025-12-29 16:32:33 +01:00
Author
Owner
Copy Link

@tduehr commented on GitHub (Jan 31, 2018):

In general, netbox lacks robust logging. At an INFO level I expect all authentication attempts and all successful actions to be logged to the console/syslog/etc.. I need to be able to audit netbox as it is (or was) used at a given time. The only way to reliably do that is through logs.

@tduehr commented on GitHub (Jan 31, 2018): In general, netbox lacks robust logging. At an INFO level I expect all authentication attempts and all successful actions to be logged to the console/syslog/etc.. I need to be able to audit netbox as it is (or was) used at a given time. The only way to reliably do that is through logs.
adam commented 2025-12-29 16:32:33 +01:00
Author
Owner
Copy Link

@pm17788 commented on GitHub (Feb 1, 2018):

I'd like to add another vote to this request.
Right now, I'm writing a bunch of Python stuff to populate data in NetBox, and, going forward, there will be tools to do reconciliation, but since I'm doing this via the API, there does not seem to be a good audit log for it.

I would argue that only the modify actions should be auditable, though, at DEBUG levels, where the implication of the performance impact is at least implied, even read APIs should be logged.

@pm17788 commented on GitHub (Feb 1, 2018): I'd like to add another vote to this request. Right now, I'm writing a bunch of Python stuff to populate data in NetBox, and, going forward, there will be tools to do reconciliation, but since I'm doing this via the API, there does not seem to be a good audit log for it. I would argue that only the modify actions should be auditable, though, at DEBUG levels, where the implication of the performance impact is at least implied, even read APIs should be logged.
adam commented 2025-12-29 16:32:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 1, 2018):

Still not clear on what you're asking for. Could you please provide example code that would accomplish what you're proposing?

@jeremystretch commented on GitHub (Feb 1, 2018): Still not clear on what you're asking for. Could you please provide example code that would accomplish what you're proposing?
adam commented 2025-12-29 16:32:33 +01:00
Author
Owner
Copy Link

@pm17788 commented on GitHub (Feb 1, 2018):

@jeremystretch: Apologies. I am not a decent enough coder to actually do that.

I'll try to rephrase for more sanity. We are talking about taking, effectively, what is the "Recent Activity" feed and putting it out to a log (be it a file or SYSLOG). The change not currently there is also logging the API access(es).

Specifically, instead of:
2018-01-30 14:09 | Modified device server515

The log line would contain:

If modified via WebUI:
{"datetime":"2018-01-30T14:12:03-05:00", "user":"pm17788", "interface":"WebUI", "operation":"modify", "id":"dcim/devices/515", "data":{"name":"server515"}}
If modified via API:
{"datetime":"2018-01-30T14:12:03-05:00", "user":"pm17788", "interface":"API", "operation":"modify", "id":"dcim/devices/515", "data":{"name":"server515"}}

Basically, a full audit log of not only the operation performed, but what were the actual data items associated with the operation. If, for example, an Interface was created, then a full JSON of the data passed is what I'd expect in the logline.

It (probably) doesn't make sense to store this sort of an audit trail in a database - long-term storage requirements get silly, but IFF feasible, having more detail in the Recent Activity log would make sense for, say, past 7 days. If I want longer retention, I get to setup separate logging.

I hope this makes sense.

@pm17788 commented on GitHub (Feb 1, 2018): @jeremystretch: Apologies. I am not a decent enough coder to actually do that. I'll try to rephrase for more sanity. We are talking about taking, effectively, what is the "Recent Activity" feed and putting it out to a log (be it a file or SYSLOG). The change not currently there is also logging the API access(es). Specifically, instead of: `2018-01-30 14:09 | Modified device server515` The log line would contain: If modified via WebUI: `{"datetime":"2018-01-30T14:12:03-05:00", "user":"pm17788", "interface":"WebUI", "operation":"modify", "id":"dcim/devices/515", "data":{"name":"server515"}}` If modified via API: `{"datetime":"2018-01-30T14:12:03-05:00", "user":"pm17788", "interface":"API", "operation":"modify", "id":"dcim/devices/515", "data":{"name":"server515"}}` Basically, a full audit log of not only the operation performed, but what were the actual data items associated with the operation. If, for example, an Interface was created, then a full JSON of the data passed is what I'd expect in the logline. It (probably) doesn't make sense to store this sort of an audit trail in a database - long-term storage requirements get silly, but IFF feasible, having more detail in the Recent Activity log would make sense for, say, past 7 days. If I want longer retention, I get to setup separate logging. I hope this makes sense.
adam commented 2025-12-29 16:32:34 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 1, 2018):

The UserAction stuff is slated to be overhauled entirely at some point (hopefully soon). #1127 has been open for a while now to convert it to use signals, but we need to go further than that. I might just expand that issue to cover this.

@jeremystretch commented on GitHub (Feb 1, 2018): The UserAction stuff is slated to be overhauled entirely at some point (hopefully soon). #1127 has been open for a while now to convert it to use signals, but we need to go further than that. I might just expand that issue to cover this.
adam commented 2025-12-29 16:32:34 +01:00
Author
Owner
Copy Link

@pm17788 commented on GitHub (Feb 1, 2018):

Cool! I would be quite willing to test, if that helps in any way.

@pm17788 commented on GitHub (Feb 1, 2018): Cool! I would be quite willing to test, if that helps in any way.
adam commented 2025-12-29 16:32:34 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 20, 2018):

Folding this into #1898

@jeremystretch commented on GitHub (Feb 20, 2018): Folding this into #1898
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#1507
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?