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

config_context is not included in default Webhook Payload any more #10995

New Issue
Closed
opened 2025-12-29 21:38:55 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:38:55 +01:00
Owner
Copy Link

Originally created by @andsch on GitHub (Apr 7, 2025).

Deployment Type

Self-hosted

NetBox Version

v4.2.4

Python Version

3.10

Steps to Reproduce

  1. create a simple POST Webhook with no further customisation that sends a JSON encoded request. Just a default data body, no templating.
  2. Create Event Rules to fire the Webhook on Changes on a device object.
  3. install a Webhook-Receiver and watch the Body content of the Webhook

Expected Behavior

the default body should include a "data" context with an exact representation of the device object as it is presented in the REST API.

Observed Behavior

the representation in the "data" context of the Webhook body is missing the field "config_context". "local_context_data" is present, but the whole Rendered config_context field, which should be between "config_template" and "local_context_data" is not present.

    [...]
    "comments": "",
    "config_template": null,
    "local_context_data": {
      "snmp": {
        "authentication_algorithm": "SHA-2-256",
        "privacy_algorithm": "AES-128",
        "user": {
          "authenticationpassword": "###",
          "privacypassphrase": "###"
        },
        "version": "3"
      }
    },
    [...]

It broke in an update from 4.1.10 to 4.2.4. We notice this behavior also in 4.2.6.

This is the whole "config_context" (with emptied values) as is is present in the REST API:

"config_context": {
        "user": "",
        "password": "",
        "snmpread": "",
        "dsl": {
            "use": "",
            "version": "",
            "password": "",
            "username": ""
        },
        "lte": {
            "use": "",
            "simpin": "",
            "password": "",
            "username": ""
        },
        "snmp": {
            "user": {
                "privacypassphrase": "",
                "authenticationpassword": ""
            },
            "version": "3",
            "privacy_algorithm": "AES-128",
            "authentication_algorithm": "SHA-2-256"
        },
        "fiber": {
            "use": "",
            "password": "",
            "username": ""
        },
        "image": "",
        "bandwidth": {
            "up": "",
            "down": ""
        },
        "ntconnect": {
            "use": "",
            "vlan": {
                "VID": "",
                "tagging": ""
            }
        },
        "enable_password": "",
        "First_Hop_Redundancy": {
            "use": "",
            "is_second": "",
            "ip_counterpart": ""
        }
    },
Originally created by @andsch on GitHub (Apr 7, 2025). ### Deployment Type Self-hosted ### NetBox Version v4.2.4 ### Python Version 3.10 ### Steps to Reproduce 1. create a simple POST Webhook with no further customisation that sends a JSON encoded request. Just a default data body, no templating. 2. Create Event Rules to fire the Webhook on Changes on a device object. 3. install a Webhook-Receiver and watch the Body content of the Webhook ### Expected Behavior the default body should include a "data" context with an exact representation of the device object as it is presented in the REST API. ### Observed Behavior the representation in the "data" context of the Webhook body is missing the field "config_context". "local_context_data" is present, but the whole Rendered config_context field, which should be between "config_template" and "local_context_data" is not present. ``` [...] "comments": "", "config_template": null, "local_context_data": { "snmp": { "authentication_algorithm": "SHA-2-256", "privacy_algorithm": "AES-128", "user": { "authenticationpassword": "###", "privacypassphrase": "###" }, "version": "3" } }, [...] ``` It broke in an update from 4.1.10 to 4.2.4. We notice this behavior also in 4.2.6. This is the whole "config_context" (with emptied values) as is is present in the REST API: ``` "config_context": { "user": "", "password": "", "snmpread": "", "dsl": { "use": "", "version": "", "password": "", "username": "" }, "lte": { "use": "", "simpin": "", "password": "", "username": "" }, "snmp": { "user": { "privacypassphrase": "", "authenticationpassword": "" }, "version": "3", "privacy_algorithm": "AES-128", "authentication_algorithm": "SHA-2-256" }, "fiber": { "use": "", "password": "", "username": "" }, "image": "", "bandwidth": { "up": "", "down": "" }, "ntconnect": { "use": "", "vlan": { "VID": "", "tagging": "" } }, "enable_password": "", "First_Hop_Redundancy": { "use": "", "is_second": "", "ip_counterpart": "" } }, ```
adam added the type: bugpending closurestatus: revisions neededseverity: low labels 2025-12-29 21:38:55 +01:00
adam closed this issue 2025-12-29 21:38:55 +01:00
adam commented 2025-12-29 21:38:56 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Apr 7, 2025):

From some cursory research, looks like the device/VM is using the DeviceSerializer rather than the DeviceWithConfigContextSerializer to serialize the data for the webhook. This might have been a casualty of a refactor.

@bctiemann commented on GitHub (Apr 7, 2025): From some cursory research, looks like the device/VM is using the `DeviceSerializer` rather than the `DeviceWithConfigContextSerializer` to serialize the data for the webhook. This might have been a casualty of a refactor.
adam commented 2025-12-29 21:38:57 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 22, 2025):

It broke in an update from 4.1.10 to 4.2.4. We notice this behavior also in 4.2.6.

I tested this on v4.1.10 and config_context was not included in the device data. I don't see how it ever would have been given that serialize_for_event() calls get_serializer_for_model(), which returns DeviceSerializer rather than DeviceWithConfigContextSerializer.

@jeremystretch commented on GitHub (Apr 22, 2025): > It broke in an update from 4.1.10 to 4.2.4. We notice this behavior also in 4.2.6. I tested this on v4.1.10 and `config_context` was not included in the device data. I don't see how it ever would have been given that `serialize_for_event()` calls `get_serializer_for_model()`, which returns DeviceSerializer rather than DeviceWithConfigContextSerializer.
adam commented 2025-12-29 21:38:57 +01:00
Author
Owner
Copy Link

@andsch commented on GitHub (Apr 23, 2025):

We are making Full-Syncs between netbox and our NMS every 6 Hours.
We additionaly are pushing interim updates via the Webhook mechanism to have a slightly more "Just-In-Time-feeling" on changes.

it is possible that this Function already was broken in 4.1.10 and simply nobody noticed it. I havn't tested it explcitly.
I received the first complains about the broken feature 1 Day after we updated to 4.2.4

The Last version we were running before 4.1.10 was 4.0.10. I'll try to fetch some backups of this versions to test the Webhooks in Detail.

We use the same Code to access payload Data on an interim Push (from the webhook Payload) and in the scheduled Full Sync (GET Call on REST API). We developed this Feature somewhere during v3.4-ish.

@andsch commented on GitHub (Apr 23, 2025): We are making Full-Syncs between netbox and our NMS every 6 Hours. We additionaly are pushing interim updates via the Webhook mechanism to have a slightly more "Just-In-Time-feeling" on changes. it is possible that this Function already was broken in 4.1.10 and simply nobody noticed it. I havn't tested it explcitly. I received the first complains about the broken feature 1 Day after we updated to 4.2.4 The Last version we were running before 4.1.10 was 4.0.10. I'll try to fetch some backups of this versions to test the Webhooks in Detail. We use the same Code to access payload Data on an interim Push (from the webhook Payload) and in the scheduled Full Sync (GET Call on REST API). We developed this Feature somewhere during v3.4-ish.
adam commented 2025-12-29 21:38:57 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 1, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (May 1, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:38:57 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 9, 2025):

This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.

@github-actions[bot] commented on GitHub (May 9, 2025): This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.
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 severity: low status: revisions needed type: bug
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#10995
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?