Add comment action parsing to authorization forms to enforce comment_edit and comment_view permissions

Background

The Sonador web application processes authorization requests from the Orthanc Advanced Authorization Plugin via PacsImagingServerGroupAuthorization.user_has_perm. Each request includes the resource level (patient/study/series/system), HTTP method, URI, resource identifiers, and token.

When a user performed a comment operation (e.g. POST /series/<id>/comments), Orthanc sent authorization checks at the patient, study, and series levels. The existing user_has_perm implementation had no handling for comment-specific operations: when method == 'post' arrived with an empty URI at the patient or study level, the code checked the modify permission instead of comment_edit. This caused the comment_edit permission to be silently bypassed — authorized users were denied (403) because they didn't have modify, while the actual comment_edit flag was never evaluated.

Changes

This issue tracks the changes in oak-tree/medical-imaging/sonador!87.

New action field parsing in authorization forms

user_has_perm now reads the action field injected by the Orthanc plugin (see orthanc-authorization!1 (merged)). When action == 'comment', the method routes to comment-specific permission checks instead of the generic modify/view/remove logic:

Write operations (method is post, put, or delete and action == 'comment'):

  • Checks comment_edit against the group's global (Sonador server-level) ACL
  • Falls through to check local (Orthanc resource-level) CommentEdit field if a local ACL exists for the resource

Read operations (method is get and action == 'comment'):

  • Checks comment_view against the group's global ACL
  • Falls through to check local CommentView field if a local ACL exists

Local ACL handling

The local (Orthanc resource-level) ACL CommentEdit and CommentView fields are evaluated when a local policy exists for the resource being accessed. A local policy granting CommentEdit: True can authorize a write operation even when the global ACL denies comment_edit, consistent with how other local ACL permissions work.

Behavioral notes

  • comment_view at the global level does not produce 403 on read operations when the user has view: True — comment reads are implicitly permitted by resource view access. CommentView: False on a local ACL does gate read access at the resource level.
  • Orthanc enforces comment authorship on PUT (update) at the application level — only the comment creator can modify comment text. This is enforced by the Orthanc comment handler regardless of ACL permissions.

Related

Project Tracking

OP#41 OP#49 OP#74

Edited by Sonador ChatGPT