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

IP-Address creation allows specifying 'dcim.cable' as 'assigned_object_type' #5176

Closed
jokvar opened this issue Sep 24, 2020 · 4 comments
Closed
Assignees
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@jokvar
Copy link

jokvar commented Sep 24, 2020

Environment

  • Python version: 3.7.5
  • NetBox version: 2.9.4
  • Pynetbox version: 5.0.8 (optional)

Steps to Reproduce

  1. Create a cable connection between any two interfaces on any two devices (in my example the cable id is 107).
  2. Using pynetbox, create an IP address, specifying any address, assigned_object_type as dcim.cable and assigned_object_id as the created cable id.
import pynetbox
nb = pynetbox.api("http://localhost", token="hidden") #token removed
ip = { 'address': '10.10.10.1/32', 'assigned_object_type': 'dcim.device_type', 'assigned_object_id': 107}
nb.ipam.ip_addresses.create(ip)
  1. Alternatively, send a Post request to the ip-addresses endpoint, specifying any address, assigned_object_type as dcim.cable and assigned_object_id as the created cable id.:
curl -X POST "http://localhost/api/ipam/ip-addresses/" -H  "accept: application/json" -H  "Content-Type: application/json" -H  "X-CSRFToken: token_removed" -d "{  \"address\": \"10.10.10.1/32\",  \"assigned_object_type\": \"dcim.cable\",  \"assigned_object_id\": 107}"
  1. Alternatively, create an IPAddress object from a script/report or using the NetBox shell, specifying assigned_object_type as the "dcim | cable" ContentType and assigned_object_id as the created cable id.:
from django.contrib.contenttypes.models import ContentType
from ipam.models import IPAddress
type = ContentType.objects.get(app_label="dcim", model="cable")
IPAddress.objects.create(address='10.10.10.1/32', assigned_object_type=type, assigned_object_id=107)
  1. Navigate to ipam/ip-addresses/ and find the created IP address.

Expected Behavior

If using pynetbox or sending a Post:

  • request fails and NetBox api returns:
    400 Bad Request: {'assigned_object_type': ['Invalid content type: dcim.cable']}

If using nbshell or a script/report:

  • creation fails with an appropriate exception regarding invalid content type.

Observed Behavior

Creation succeeds. The IP address shows a tick in the "Assigned" label.
If this was done using pynetbox, navigating to the IP address view also shows the cable label as its "Assignment". This field is empty otherwise.

Important Notes

The NetBox shell/script/report method allows specifying any invalid content type (provided it can be obtained from ContentTypes) - will save it and never display it to a user.
The API call allows specifying some invalid object types, I have successfully assigned 'virtualiztion.cluster' but not 'extras.tags'.
The only invalid object type Pynetbox allows assigning is 'dcim.cable' for some reason - the cluster type attempt fails properly.

@lampwins
Copy link
Contributor

Not only is this case possible, but you can also set assigned_object_type to null and still provide an assigned_object_id.

@lampwins lampwins added status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application labels Sep 26, 2020
@jeremystretch
Copy link
Member

The root issue seems to be that limit_choices_to doesn't actually enforce any form of validation, which we've overlooked. AFAICT we'll need to implement custom validation for every ForeignKey to the ContentType model. (This seems wrong, but I haven't come across any documentation that indicates otherwise.)

The following fields are likely affected:

  • dcim.Cable: termination_a_type, termination_b_type
  • extras.ImageAttachment: content_type
  • ipam.IPAddress: assigned_object_type (as noted above)

@jeremystretch
Copy link
Member

This is likely solved by extending ValidatedModelSerializer.validate() to call full_clean() on the faux instance. (DRF does not, in fact, invoke model validation on its own, as discussed here.)

@jeremystretch
Copy link
Member

This has been addressed in develop-2.10 and will be fixed in the v2.10 release.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

3 participants