recaptime.dev / phorge
@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.) hq.recaptime.dev/wiki/Phorge
phorge phabricator
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Fix excessively strict "Can Use Application" policy filtering

Summary:
Ref T9058. The stricter filtering is over-filtering Handles. For example, in the Phacility cluster, users can not see Almanac services.

So this filtering happens:

- The AlmanacServiceQuery filters the service beacuse they can't see the application.
- The HandleQuery generates a "you can't see this" handle.
- But then the HandleQuery filters that handle! It has a "service" PHID and the user can't see Almanac.

This violates the assumption that all application code makes about handles: it's OK to query handles for objects you can't see, and you'll get something back.

Instead, don't do application filtering on handles.

Test Plan:
- Added a failing test and made it pass.
- As a user who can not see Almanac, viewed an Instances timeline.
- Before patch: fatal on trying to load a handle for a Service.
- After patch: smooth sailing.

Reviewers: chad

Maniphest Tasks: T9058

Differential Revision: https://secure.phabricator.com/D17152

epriestley f16778fc d4248d23

+33
+13
src/applications/policy/filter/PhabricatorPolicyFilter.php
··· 874 874 $viewer = $this->viewer; 875 875 876 876 foreach ($objects as $key => $object) { 877 + // Don't filter handles: users are allowed to see handles from an 878 + // application they can't see even if they can not see objects from 879 + // that application. Note that the application policies still apply to 880 + // the underlying object, so these will be "Restricted Object" handles. 881 + 882 + // If we don't let these through, PhabricatorHandleQuery will completely 883 + // fail to load results for PHIDs that are part of applications which 884 + // the viewer can not see, but a fundamental property of handles is that 885 + // we always load something and they can safely be assumed to load. 886 + if ($object instanceof PhabricatorObjectHandle) { 887 + continue; 888 + } 889 + 877 890 $phid = $object->getPHID(); 878 891 if (!$phid) { 879 892 continue;
+20
src/applications/project/__tests__/PhabricatorProjectCoreTestCase.php
··· 51 51 $proj, 52 52 PhabricatorPolicyCapability::CAN_VIEW)); 53 53 54 + // This object is visible so its handle should load normally. 55 + $handle = id(new PhabricatorHandleQuery()) 56 + ->setViewer($user) 57 + ->withPHIDs(array($proj->getPHID())) 58 + ->executeOne(); 59 + $this->assertEqual($proj->getPHID(), $handle->getPHID()); 60 + 54 61 // Change the "Can Use Application" policy for Projecs to "No One". This 55 62 // should cause filtering checks to fail even when they are executed 56 63 // directly rather than via a Query. ··· 75 82 $user, 76 83 $proj, 77 84 PhabricatorPolicyCapability::CAN_VIEW)); 85 + 86 + // We should still be able to load a handle for the project, even if we 87 + // can not see the application. 88 + $handle = id(new PhabricatorHandleQuery()) 89 + ->setViewer($user) 90 + ->withPHIDs(array($proj->getPHID())) 91 + ->executeOne(); 92 + 93 + // The handle should load... 94 + $this->assertEqual($proj->getPHID(), $handle->getPHID()); 95 + 96 + // ...but be policy filtered. 97 + $this->assertTrue($handle->getPolicyFiltered()); 78 98 79 99 unset($env); 80 100 }