problem

The active VisualReview plugin loads the current task and the user's current job during annotation controller initialization. However, AnnotationController::indexAction() discards this secure server-side binding when the request contains its own taskGuid. In that case, annotations are filtered by the client-provided task GUID instead of the current task context.

Code review showed no legitimate need for plugins_visualreview_annotation to accept a client-provided taskGuid. The frontend currently sends Editor.data.task.get('taskGuid'), which duplicates the already active task context available server-side. For new annotations, the frontend also sets taskGuid and userGuid, but both values can and should be derived from the current server-side task, session, and job context.

The generic REST write paths require hardening: incoming request data is copied into entity fields, and VisualReview annotations expose taskGuid and userGuid as regular fields. This means client-provided task or user identifiers may influence persisted annotation data unless the annotation controller strips, overwrites, or validates them explicitly.

Once a user has an active job and annotations exist for other tasks, the user may likely be able to address foreign annotations or create data under foreign task or user identifiers. A concrete modification of foreign annotations was not proven in the test system.

solution

Remove client-provided taskGuid from the VisualReview annotation API contract. Annotation reads must always filter by the current server-side task context.

For annotation creation, ignore incoming taskGuid and userGuid and set both values exclusively from the current server-side task, authenticated user, and job context.

For annotation updates and deletes, load the annotation by ID and explicitly verify that its taskGuid matches the current task before modifying it. Additionally enforce the applicable ownership and role rules before read, write, update, or delete operations.

The frontend should stop sending taskGuid and userGuid for annotation loads and creates. Keeping those fields temporarily for compatibility is acceptable only if the backend ignores or overwrites them.

Add tests covering cross-task read/write/delete attempts and manipulation of client-submitted taskGuid / userGuid.