mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-27 17:22:42 +01:00
db1cd65866
Summary: Fixes T8198. Currently, if the `policy.locked` configuration setting includes a value which is a user PHID, we may perform a cache fill during setup as a side effect of validating it. Right now, there is no WriteGuard active during setup, because we don't have a Request object yet so we can't actually perform CSRF validation. Two possible approaches are: # Prevent the write from occuring. # Change the code to allow the write. In the past, I think we've hit similar cases and done (1). However, IIRC those writes were sketchier, more isolated, and easy to remove (I think there was one with PKCS8 keys). This one is pretty legit and not very easy to remove without making a bit of a mess. There's no techncial reason we can't do (2), we just have to create a no-op WriteGuard for the setup phase. Test Plan: - To reproduce this issue: set some value in `policy.locked` to a user PHID, then wipe out profile caches in the database, then restart the webserver. - Reproduced the issue. - Added the new dummy write guard, fixed a minor issue with disposal semantics (see D12841). - Verified this fixed the issue. - Added a `throw` to the real CSRF validator and performed a real write. Verified I got CSRF-blocked. - Removed a CSRF token from a form and double-checked that CSRF protection still works. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8198 Differential Revision: https://secure.phabricator.com/D12842 |
||
|---|---|---|
| .. | ||
| __tests__ | ||
| configuration | ||
| exception | ||
| response | ||
| sink | ||
| AphrontController.php | ||
| AphrontRequest.php | ||
| AphrontURIMapper.php | ||