Files
ignacionelson 922be7226c Let a client edit and delete the files they uploaded
A client could upload a file and then never touch it again. No rename, no
description, no expiry, no categories, no delete — the portal has three
file routes and all three are GET. Meanwhile the Roles screen happily
grants the Client role edit_files, delete_files, set_file_categories,
set_file_expiration_date and upload_public, and every one of them was
inert, because the routes that honour them are `staff`-gated rather than
permission-gated. That is what #1771 hit: a permission granted, saved, and
silently doing nothing.

A client owns what they uploaded. Ownership is now what lets them edit and
delete it, subject to the same per-field keys staff are subject to.

The obvious implementation is a trap, and it is worth writing down. Both
policy methods began `if (! $user->isStaff()) return false;` and both end
in StaffLibraryScope, whose allowsFile() reads `if (! isClientScoped())
return true` — and isClientScoped() is `isStaff() && role->client_scoped`,
so it is false for every client. Delete the early return and a client
falls into the branch meaning "this staff member is unrestricted" and is
handed the whole library. Same for folders(), which returns an unfiltered
query: a client could move their file into any folder on the installation.
So clients get their own branch, reaching neither. The portal asks
Folder::uploadableBy() instead — a file cannot be moved somewhere it could
not have been uploaded.

edit_others_files and delete_others_files stay inert for clients by
construction. A client has no others' files, only files somebody showed
them, and being shown a file is not being given it.

Which fields an editor may write moved into ApplyFileEdits, shared by the
staff editor, /api/v1 and the portal. There were two copies of the same
eight permission checks and this would have been the third; the checks are
easy, which is exactly why the drift would have been invisible. Callers
normalise their own request shape, this gates and writes and logs. Expiry
reading and writing came along too, as FileExpiry — three copies, of which
only the API's could read a timestamp.

Clients do not choose the public slug. It is derived from the name they
already picked, because an installation-wide unique slug a client sets is
a name to squat and an existence oracle to probe with.

One consequence for later, written up in docs/api-todo.md: the policy now
says yes to a client for file writes, so `staff-token` is the only thing
holding the API boundary where there used to be two independent refusals.
ActorBoundaryTest pins it, and asserts the policy passes first so the test
cannot quietly stop testing the middleware.

Also corrects a stale comment that claimed a deleted file's bytes stay on
disk. They have not since File::booted() grew a `deleted` hook; nothing
ever forceDelete()s a File row, so "until a purge lands" would have meant
never — which is why a client's delete frees their quota by exactly what
it frees on disk.

The UI comes next; this is the authorization, the routes and the tests.

Fixes #1771
2026-09-07 02:37:26 -03:00

110 lines
4.4 KiB
PHP

<?php
declare(strict_types=1);
namespace App\Modules\Files;
use App\Models\User;
use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Files\Models\File;
/**
* Ownership rules as policy methods (brief §6.13): "own" versus
* "others'" files map onto the v1 permission pairs. Clients may only
* view/download what is assigned to them, directly or via a group, and may
* edit or delete only what they uploaded themselves. For client-scoped
* staff, every action is additionally gated by the StaffLibraryScope, so
* direct access can't reach out-of-scope files.
*
* Every method here branches on isStaff() before it reaches the scope.
* That is not stylistic: StaffLibraryScope answers "is this *restricted*
* staff member allowed?", and its "no restriction" answer is `true`. A
* client falling through to it is handed the whole library. See update().
*/
class FilePolicy
{
public function __construct(
private readonly StaffLibraryScope $scope,
) {}
public function view(User $user, File $file): bool
{
if ($user->isStaff()) {
return ($user->can('upload') || $user->can('edit_files') || $user->can('edit_others_files'))
&& $this->scope->allowsFile($user, $file);
}
return File::query()->whereKey($file->id)->visibleToClient($user)->exists();
}
public function update(User $user, File $file): bool
{
// A client edits what they uploaded and nothing else. Deliberately
// its own branch rather than a shared one, because the staff branch
// below is unsafe for a client in two ways at once.
//
// First, `edit_others_files` must never be reachable here. It is a
// staff key by construction: a client has no "others' files" they
// could hold a legitimate claim over, only files somebody shared
// with them, and being shown a file is not being given it. Granting
// that key to the Client role does nothing, and a test pins that.
//
// Second, and the trap: StaffLibraryScope::allowsFile() returns
// true outright for anyone who is not client-*scoped* staff —
// User::isClientScoped() is `isStaff() && role->client_scoped`, so
// it is false for every client. That predicate means "this staff
// member is unrestricted", and a client reaching it would inherit
// "unrestricted" over the whole library. Nothing here may touch the
// staff scope.
if (! $user->isStaff()) {
return $file->isOwnedBy($user) && $user->can('edit_files');
}
$permitted = $file->isOwnedBy($user) ? $user->can('edit_files') : $user->can('edit_others_files');
return $permitted && $this->scope->allowsFile($user, $file);
}
/**
* May this user use $file as either end of a version link?
*
* Checked on BOTH ends by FileVersions::link(), and that is the whole
* control — the candidate endpoints filter the same way, but a
* previous_file_id can be posted directly, so filtering the picker is
* a courtesy and this is the boundary.
*
* Staff get the same rule as editing, because linking moves the
* subject's assignment rows onto the original and so widens the
* original's audience — a strictly bigger act than reading it.
*
* A client gets their OWN UPLOADS ONLY, deliberately not
* ViewableFileScope: a client can see every file staff shared with
* them, and since a revision inherits the original's recipients,
* letting a client name a shared file as their upload's original
* would hand that upload the entire recipient list of a file they do
* not own. That is the escalation this method exists to stop.
*/
public function setVersion(User $user, File $file): bool
{
if ($user->isStaff()) {
return $this->update($user, $file);
}
return $file->isOwnedBy($user);
}
public function delete(User $user, File $file): bool
{
// Their own upload, and only with the key — same two reasons as
// update() above, `delete_others_files` standing in for
// `edit_others_files`.
if (! $user->isStaff()) {
return $file->isOwnedBy($user) && $user->can('delete_files');
}
$permitted = $file->isOwnedBy($user) ? $user->can('delete_files') : $user->can('delete_others_files');
return $permitted && $this->scope->allowsFile($user, $file);
}
}