Skip to content

Conversation

jnovinger
Copy link
Member

@jnovinger jnovinger commented Oct 13, 2025

Closes: #16681

Add render_config permission action for rendering device, virtual machine, and config template configurations via the REST API.

Changes:

  • Add permission checks to /api/dcim/devices/{id}/render-config/, /api/virtualization/virtual-machines/{id}/render-config/, and /api/extras/config-templates/{id}/render/
  • Introduce TokenWritePermission to enforce token write ability independent of model permissions
  • Replace POST='add' requirement with render_config permission
  • Add test coverage and documentation

Per #16681: rendering configs requires accepting arbitrary user data (requiring write-enabled tokens), but doesn't require permission to create devices/VMs. The render_config permission separates these concerns.

Note: Optional data migration could grant render_config to existing users with view or add permissions to ease upgrade path. Can add if desired.

…endering

Add a new custom permission action `render_config` for rendering device and
virtual machine configurations via the REST API. This allows users to render
configurations without requiring the `add` permission.

Changes:
- Add permission check to RenderConfigMixin.render_config() for devices and VMs
- Update API tests to use render_config permission instead of add
- Add tests verifying permission enforcement (403 without render_config)
- Document new permission requirement in configuration-rendering.md

Note: Currently requires both render_config AND add permissions due to the
automatic POST='add' filter in BaseViewSet.initial(). Removing the add
requirement will be addressed in a follow-up commit.
Remove the add permission requirement from the render-config API endpoint
while maintaining token write_enabled enforcement as specified in #16681.

Changes:
- Add TokenWritePermission class to check token write ability without requiring
  specific model permissions
- Override get_permissions() in RenderConfigMixin to use TokenWritePermission
  instead of TokenPermissions for render_config action
- Replace queryset restriction: use render_config instead of add
- Remove add permissions from tests - render_config permission now sufficient
- Update tests to expect 404 when permission denied (NetBox standard pattern)

Per #16681: 'requirement for write permission makes sense for API calls
(because we're accepting and processing arbitrary user data), the specific
permission for creating devices does not'
Extend render_config permission requirement to the ConfigTemplate render
endpoint per issue comments.

Changes:
- Add TokenWritePermission check via get_permissions() override in
  ConfigTemplateViewSet
- Restrict queryset to render_config permission in render() method
- Add explicit render_config permission check
- Add tests for ConfigTemplate.render() with and without permission
- Update documentation to include ConfigTemplate endpoint
def get_permissions(self):
# For render action, check only token write ability (not model permissions)
if self.action == 'render':
return [TokenWritePermission()]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we still need to enforce view permissions for the ConfigTemplate itself.

def get_permissions(self):
# For render_config action, check only token write ability (not model permissions)
if self.action == 'render_config':
return [TokenWritePermission()]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As with ConfigTemplateViewSet, I think we still need to enforce view permission for the device/VM for which the template is being rendered.

Remove redundant permission checks, add view permission enforcement via
chained restrict() calls, and rename ConfigTemplate permission action
from render_config to render for consistency.
@jnovinger
Copy link
Member Author

jnovinger commented Oct 16, 2025

I may have over-corrected a little on enforcing the view permissions, enforcing them on both the object in question and for the associated config template. Also, trying to be consistent, I enforced the view permissions by chaining another .restrict(request.user, 'view') for enforcing it for the object in question and with has_perm(...) for the associated config template.

If any of these aren't the best way to do this, please let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants