>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3613945. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !384 >>> <p>Two defects, and the second is what made the first possible.</p> <p><strong>To reproduce</strong></p> <ol> <li>Model a workflow whose human step hands off to a webform, and configure that step to display some context, such as an earlier reviewer's comment.</li> <li>Let a run park on the step, assigned to an operator, and open it from that operator's inbox. The webform URL carries the binding and the continuation handle as query values.</li> <li>Take the work away from that user: reassign the step, or, if they only reached it as somebody's stand-in, revoke the delegation.</li> <li>Revisit the same URL as that user.</li> </ol> <p><strong>Expected:</strong> 403. The step is not theirs to act on.</p> <p><strong>Actual:</strong> the page renders, the step's configured context is posted to them as messages, and the form is offered as though submitting it would do something. Submitting is in fact refused, which is correct, but silently: the visitor gets a saved submission and no indication that the workflow ignored it.</p> <p><strong>Why it went unnoticed.</strong> Binding and resuming were both already gated, so nothing could be changed through this page. What was missing was the disclosure and the false affordance, and neither had an assertion anywhere: the render path had no access check at all, and the submit path returned FALSE without telling anybody.</p> <p><strong>The defect underneath.</strong> Acting on a step and being shown one are two different permissions, and the two doorways disagree about exactly that. On the bearer doorway possession authorizes viewing, and <code>CapabilityGateway::authorize()</code> deliberately returns the negation of <code>assigned()</code> so the dispatcher can show an assigned step's status while refusing to complete it. On an identity doorway possession authorizes nothing. So the obvious fix, gating the render on the existing <code>authorize()</code>, would have been a regression rather than a fix.</p> <p>More generally, the access API returned <code>bool</code>. A boolean can state a verdict but not what invalidates it, and here that is not academic: a standing delegation is dated, so cover lapses with the clock and nothing is written when it does. Two access checks elsewhere in the project had already hit the same wall and answered it with <code>setCacheMaxAge(0)</code>, which is the honest answer to a question the API could not express, and an expensive one.</p> <p><strong>Proposed fix</strong></p> <ol> <li>Add <code>InteractionAccessInterface</code> with <code>mayView()</code> and <code>mayComplete()</code>, both returning <code>AccessResultInterface</code>, and have <code>InteractionResumerInterface</code> extend it. The bearer gateway allows viewing unconditionally; the identity resumers answer viewing exactly as they answer completing, because what a step renders is the workflow's own context.</li> <li>Refuse the page in the handler when the bound step exists and its doorway refuses the viewer, and warn instead of staying silent when a submission is refused. A handle that resolves to nothing is left alone, since it binds nothing and the unresolved-binding message already covers it.</li> <li>Replace <code>WorkItemManager::userCanAct()</code> with <code>actAccess()</code>, returning an access result that carries the task, the acting user and the delegation set. <code>DelegationResolverInterface</code> becomes a cacheable dependency reporting the nearest window boundary it consulted, so a lapsing delegation expires the decisions taken from it.</li> <li>Make the tenant seam report its own cacheability, so a resolver declares what it read (a host, an OAuth consumer) instead of every consumer guessing, and drop <code>setCacheMaxAge(0)</code> from both access checks. <code>InstanceReadScope</code> declares the whole read-scope chain, not just the link that answered, since adding an override changes which link wins.</li> </ol> <p>Both access checks now pin their dependency set in a test. That is the only level this class of bug is visible at: every existing test calls the check directly and reads the boolean, which recomputes every time, so nothing in the suite could have caught a missing tag.</p> <p><strong>Note on scope.</strong> The submission data itself is governed by Webform's own permissions ("view any webform submission" and friends), which is a separate matter and correctly not Orchestra's to override: a forbidden result from Orchestra would win over every allow and lock administrators out of the results UI. What this issue is about is the step context Orchestra posts on its own account, the silent refusal, and the API that could not express either gate.</p> <p>Filed publicly: the project is covered by the security advisory policy, but that policy applies to supported stable releases and there is no stable release yet, only 1.0.0-alpha1, so this is not a security team matter. Found while reviewing the delegation work in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/orchestra/-/work_items/3613914" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/orchestra/-/work_items/3613914</a></span>, where revoking a delegation correctly closed the ability to act while the page still rendered.</p> <p><strong>Also in this MR</strong></p> <p>Two things landed here that the summary above does not describe. Recording them so a reviewer is not surprised.</p> <p><strong>Invalidation fixes for output that outlived what it rested on.</strong> Removing <code>setCacheMaxAge(0)</code> exposed a class of bug the project already had: a surface declaring <code>Cache::PERMANENT</code> and no tags while its output depends on standing cover, which is dated and so begins and lapses with nothing written. Five surfaces were affected: <code>TaskOperations</code>, <code>TaskActLink</code>, <code>WorkItemHolder</code>, <code>InstanceActLink</code>, and the delegations listing itself, whose Status column reported "Not started" after cover had begun. Each now declares what the matcher reports plus the acting account, and the listing derives a max-age from the rows it rendered.</p> <p><strong>The two directions of cover, as tabs.</strong> A stand-in had no page answering "why are someone else's tasks in my inbox, and until when?" <code>/orchestra/delegations</code> now has <em>My delegations</em> (cover you asked for) and <em>Delegated to me</em> (cover you provide). The second is read-only, since a stand-in withdrawing cover would leave the delegator believing they were still covered, and it lists only cover still in force or still to come, so a delegator keeping lapsed rows does not clutter somebody else's page. It carries its own menu entry because the tab hangs off a route requiring "delegate own orchestra tasks", which somebody who only ever stands in has no reason to hold.</p> <p>Both are here rather than in their own issues because they were found by this work and are the same subject at the layer below: a decision, and what it rests on.</p>