Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Webhooks sent despite protection rule block #15090

Closed
ryankearney opened this issue Feb 8, 2024 · 2 comments · Fixed by #15196
Closed

Webhooks sent despite protection rule block #15090

ryankearney opened this issue Feb 8, 2024 · 2 comments · Fixed by #15196
Assignees
Labels
severity: medium Results in substantial degraded or broken functionality for specfic workflows status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@ryankearney
Copy link

Deployment Type

Self-hosted

NetBox Version

v3.7.2

Python Version

3.10

Steps to Reproduce

  1. Create a webhook that triggers on an IP Address delete
  2. Create a custom protection rule that will block deletion if IP addresses. For example: { "ipam.ipaddress": [ { "status": { "eq": "deprecated" } } ] }
  3. Go delete an IP address object that does not satisfy the protection rule
  4. Observe the error message Deletion is prevented by a protection rule: {'status': ['Ensure this value is equal to deprecated.']} (this is expected)
  5. Observe the webhook firing for an ipaddress deletion (this is unexpected)

Expected Behavior

Webhook should not fire on deletion if a protection rule prevented the deletion from happening.

Observed Behavior

Webhook is sent sent with event deleted and a snapshot.postchange value of null despite the system blocking this deletion. This could have implications on webhook receivers processing the deletion when in fact the object remains in NetBox.

@ryankearney ryankearney added the type: bug A confirmed report of unexpected behavior in the application label Feb 8, 2024
@renatoalmeidaoliveira
Copy link
Contributor

I can think in two ways to solve this Issue
1 Change handle_deleted_object event to post_delete.
2 Join handle_deleted_object and run_delete_validators in a single pre_delete method.
If I would fix that issue I would go for option 2.
I can make a fix for that issue, just let me know which path is the best.

@jeremystretch
Copy link
Member

  1. Change handle_deleted_object event to post_delete.

I don't think this is feasible, because the receiver function is also responsible for recording a change record. This must happen before the object is deleted e.g. to retain its primary key.

  1. Join handle_deleted_object and run_delete_validators in a single pre_delete method.

IMO this would be the preferred solution.

@jeremystretch jeremystretch added status: under review Further discussion is needed to determine this issue's scope and/or implementation severity: medium Results in substantial degraded or broken functionality for specfic workflows labels Feb 13, 2024
@jeremystretch jeremystretch self-assigned this Feb 15, 2024
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: medium Results in substantial degraded or broken functionality for specfic workflows status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants