gsadmin/projectsend
1
0
Fork 0
mirror of https://github.com/projectsend/projectsend.git synced 2026-10-04 13:33:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

Compare commits

base: gsadmin/projectsend:v2.2.0
Branches Tags
gsadmin/projectsend:main gsadmin/projectsend:design/favicon-square-mark gsadmin/projectsend:docs/readme-projectsend-cloud gsadmin/projectsend:feature/gcs-storage gsadmin/projectsend:fix/trusted-proxies-read-from-env
gsadmin/projectsend:v2.6.0 gsadmin/projectsend:v2.5.0 gsadmin/projectsend:v2.4.1 gsadmin/projectsend:v2.4.0 gsadmin/projectsend:v2.3.0 gsadmin/projectsend:v2.2.1 gsadmin/projectsend:v2.2.0 gsadmin/projectsend:v2.1.0 gsadmin/projectsend:v2.0.0
...
compare: gsadmin/projectsend:v2.4.1
Branches Tags
gsadmin/projectsend:main gsadmin/projectsend:design/favicon-square-mark gsadmin/projectsend:docs/readme-projectsend-cloud gsadmin/projectsend:feature/gcs-storage gsadmin/projectsend:fix/trusted-proxies-read-from-env
gsadmin/projectsend:v2.6.0 gsadmin/projectsend:v2.5.0 gsadmin/projectsend:v2.4.1 gsadmin/projectsend:v2.4.0 gsadmin/projectsend:v2.3.0 gsadmin/projectsend:v2.2.1 gsadmin/projectsend:v2.2.0 gsadmin/projectsend:v2.1.0 gsadmin/projectsend:v2.0.0

207 Commits
v2.2.0 ... v2.4.1

Author SHA1 Message Date
ignacionelson b8050b36ca Release 2.4.1 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CNFU55Tkq6MuEQ73nbbBRx
 2026-09-11 13:59:02 -03:00
ignacionelson da5aadd1f3 Cut the 2.4.1 entry down to what changed, and add what was missing 
Three entries were absent. A sweep of every commit since v2.4.0 for code
changes with no changelog line returned thirteen; ten were correctly absent
— the announcement work is a seam with no content on a self-hosted install,
the client share link is always null unless a platform module mints one, the
quota floor is a platform environment variable, and the email_verified_at
change is inert while MustVerifyEmail is off. The other three were real:

  - the IAM-role feature, a visible control on the storage settings screen
    that every self-hosted administrator can reach, with no entry at all;
  - #1770, a Docker upgrade that fails outright when external storage is
    already configured, which is exactly what a changelog is for;
  - download counts on a client's own files, which OwnFileDownloads gates
    on nothing, so it is live everywhere.

Every entry is now one line. The explanatory paragraph, the "who this
affected" note and the upgrade advice are gone from the change list; what an
operator must actually do was already collected at the top and stays there,
because a title alone cannot be acted on.

Reordered so the account takeovers lead rather than sitting ninth and
eleventh behind a thumbnail-rendering fix, and the two public-folder entries
sit together — they are one boundary reported in two halves, and had six
entries between them.

All seven reporters keep their credit, moved inline.

Version is the user's call, recorded here rather than argued: 2.4.1. Note
that the file's own rule above says the last number moves when there are
only fixes, and this entry has an Added section.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CNFU55Tkq6MuEQ73nbbBRx
 2026-09-11 13:55:06 -03:00
ignacionelson 386cb32ebb Translate the four strings that accumulated since 2.4.0 
Sixteen locales, four strings each, which is the whole of what had drifted:
three from the IAM-role work (the toggle, its explainer, and the warning
that saving clears a stored key and secret) and one from this week's upload
limits ("Too many uploads are already in progress").

Terminology was taken from each catalogue rather than chosen: every locale
already had "Access key" and "Secret key", and the new strings reuse those
words exactly, so the explainer reads in the same vocabulary as the two
fields directly beneath it. Product nouns stay as they are — AWS, IAM, ECS,
EC2, EKS/IRSA, MinIO, Backblaze, Wasabi, ProjectSend.

Formality was read off each file instead of assumed: informal in ca, es, it,
nl and zh_CN, formal in cs, de, fr, id, pl, pt_BR, ru and tr, matching what
the neighbouring sentences already do. Spanish has three voseo entries among
thirty-three tuteo ones — they arrived with the password-reset work on
2026-09-08 (df44c46a, 6339ae15) and are the outliers, so these follow the
tuteo the rest of the file uses. Worth settling one way or the other by
somebody who speaks it, which is not a job for this commit.

The edits are additive: no entry reordered or rewritten, so the diff is the
four new lines per file and the comma the previous last line grew.

Verified past the point where a JSON file merely parses. The scanner reports
0 missing across all sixteen, the Locale suite passes, and the Spanish
strings were read off a rendered page in a browser — signed in, interface
switched to Spanish through the app's own control, with the explainer
wrapping to four lines inside its column and reading in the same words as
the "Clave de acceso" and "Clave secreta" labels under it. That screen only
draws its S3 half when the provider is S3 and the dev instance is on GCS, so
the provider was flipped for the reading and put back; it was snapshotted
first and restored to what it was, not to a default.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CNFU55Tkq6MuEQ73nbbBRx
 2026-09-11 13:26:08 -03:00
ignacionelson 38400956bc Put the installation's own logo on the pages people sign in through 
Requested by @Zodiac1978 in #1777.

The logo already replaced ours in the staff sidebar, on the public listing
and in the client portal. The sign-in screen still wore the ProjectSend
wordmark — and that is the first page of yours most people ever see, and
often the only one a client sees, because it is where the link in a
notification email lands them.

One layout serves every screen reached before signing in, so this covers
login, registration, both password-reset pages, the two-factor challenge,
first-run setup and the page a share link opens. That breadth is the reason
to change the layout rather than the login page: the same visitor moves
between several of them in one sitting, and a logo that appeared on one and
not the next would read as a different site.

Nothing needed gating. `branding.logo_url` is already shared on every
request and is already null wherever the Branding capability is absent, so
an installation that has withheld branding, or never uploaded anything,
renders exactly what it rendered before.

Three tests cover the server's half — the prop reaching a page nobody has
signed in to see, the null fallback, and the capability being taken away.
None of them can say whether the component mounted or the image resolved,
so that was checked in a real browser: headless Chrome against the dev
instance with a logo installed reports the <img> present, naturalWidth 360
(so it decoded rather than sitting broken) and a rendered height of 48px,
and with the logo removed reports no <img> and the fallback SVG in its
place. The branding row was snapshotted before and restored after.

One thing worth knowing, unchanged by this and not introduced by it: a logo
drawn for a white background is hard to read on the dark theme, here and on
every other surface that shows it, because none of them filter the artwork.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CNFU55Tkq6MuEQ73nbbBRx
 2026-09-11 13:00:38 -03:00
ignacionelson 8aef6e5b5a Tell an Apache install what it needs, and where its 500 is written 
Reported by @Zodiac1978 in #1778, on IONOS.

Step 6 was nginx and only nginx, while "What you need" says Apache is fine.
It is fine, but not without being told two things — document root at
public/, and AllowOverride All with mod_rewrite on, or the .htaccess we ship
does nothing and every address but the home page is a 404. There is now an
Apache vhost beside the nginx one.

The 500 in the report is its own troubleshooting entry, because the entry we
had sends people to storage/logs/ and for this class of failure that
directory is empty — Apache never reached PHP, so ProjectSend had nothing to
write, and an empty log reads as a dead end rather than as the clue it is.
The error is in Apache's log. Two causes cover nearly all of them: Options
refused by AllowOverride, and the internal-redirect loop this reporter hit,
where Apache cannot derive the per-directory base and the front-controller
rule rewrites to a path that is not there, repeatedly.

public/.htaccess now carries a commented-out RewriteBase with the
explanation next to it, which is where somebody debugging a 500 is already
looking.

Only RewriteBase is documented, not the report's second change — making the
substitution absolute (`/index.php`). With the base set correctly the
relative form resolves to the same place, and the absolute one would send a
subdirectory install to the domain root's index.php instead.

The trap underneath all of this is worth its own paragraph, and nothing said
it before: update.sh merge-copies the release over the install, so an edit
to public/.htaccess is reverted on the next update and the site 500s again.
Put the directives in the vhost if it is yours to edit, since an update
cannot reach there — and on shared hosting, where it is not, keep a note.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CNFU55Tkq6MuEQ73nbbBRx
 2026-09-11 12:45:26 -03:00
ignacionelson 8372f42525 Ask the picker's own question of what comes back from it 
Reported by @skeletonsec as GHSA-w29w-pj29-x7ww.

Deleting an account that owns files makes the admin choose who inherits
them. The picker narrows that list for a client-scoped staff member to their
own roster, and says why two methods up: "a client-scoped staff member is
not shown the name of somebody they can reach nothing of, and a picker is no
more a reason to hand one over than a listing is."

The write asked something else entirely — exists, active, and not the
account being deleted. All three are true of every account on the
installation. So a scoped staffer could name an id the picker had
deliberately kept off the list, and a roster client's files and folders
landed with a client on somebody else's roster: readable, editable and
deletable there, because a client owns what they uploaded and
visibleToClient() includes uploaded_by.

The entry doors scope the source account and always did — guardTarget goes
through canAssignClient. It is the destination nobody scoped.

candidates() and validate() now run one predicate, reachableTargets(),
rather than two that happened to agree. Two that agree by inspection is what
this was: the narrowing existed, was correct, and was only ever applied to
the list.

The refusal deliberately reads as "no such account". An out-of-roster id and
an id belonging to nobody now produce the same message, because a refusal
that distinguishes them lets a scoped staffer walk the id space and learn
which accounts exist outside their roster. That is why Rule::exists is gone
rather than kept alongside: one code path, one answer. A test pins the two
messages as identical instead of naming either.

Both the web screen and the API twin come through this one validate(), so
both are fixed by it — and the test file proves each separately rather than
assuming the sharing holds.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CNFU55Tkq6MuEQ73nbbBRx
 2026-09-11 12:19:28 -03:00
ignacionelson 50f8b578df Ask the publication question wherever content lands, not just on upload 
Reported by @skeletonsec as GHSA-rxf8-wh8v-jm9j.

A file in a public folder is public: isEffectivelyPublic() is "my own flag,
or my folder's", read up the whole ancestry. GHSA-237r-jx85-j3hr settled
that three days ago, put the rule in Folder::uploadableBy(), and wired it
into the upload paths.

Content arrives in a folder four other ways. move() drags one file in,
bulkUpdate() moves a selection, update() reparents through the edit form,
and FoldersController::move() drags a whole folder — every file in its
subtree — under a public parent. Each of them asked whether the destination
was *visible* to the mover and then wrote folder_id. Visible is not the same
question as publishable, and the difference is the entire permission: a
staff member given editing rights and deliberately not given upload_public
could publish confidential files to the anonymous site by choosing where
they landed. The API twin of update() had the same gap.

Both earlier advisories named these paths in their own "suggested fix"
sections. Neither demonstrated them, so neither was followed. The fix to a
report wants the scrutiny the report got, and this one did not get it.

The predicate did not need changing — it needed calling. Four sinks now ask
it, plus the API twin. The check stays split in two deliberately: the
destination is resolved through StaffLibraryScope as before, so a folder
somebody cannot see is still a 404 and not an existence oracle, and the
publication clause is a separate 403 on top. They agree by construction —
allowsFolder() is folders()->whereKey()->exists() — so nothing that used to
resolve can now fail the first half.

On the file paths the check fires only when folder_id actually changes,
which is the convention already there: re-saving a file that sits in a
folder out of the saver's scope must keep working. bulkUpdate() checks its
destination once instead, before the loop, because there is one destination
for the batch and if it publishes then no file in the batch may go.

Folder::uploadableBy()'s docblock now says to read the name as "may place
into", with why: the name is what made this easy to miss, and the next
folder_id or parent_id write will be written by somebody reading it.

Ten tests, one per sink with a private-destination control beside it, plus
an editor who *can* publish to show the boundary is about publishing and not
about moving. The last one follows the advisory's own chain to the end and
asserts the thing actually claimed — a stranger with no session, no token
and no assignment fetching the anonymous download URL. It returns 200 on the
code before this commit and 404 after.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CNFU55Tkq6MuEQ73nbbBRx
 2026-09-11 12:16:23 -03:00
ignacionelson 6ad26bb61e Hold an upload to the size it said it was sending 
Reported by @ry2811 as GHSA-6jh6-gvj5-pv8v.

A resumable upload declares its size, and that declaration is what store()
weighs against the maximum file size and the client's storage quota. Only
the assembled file was ever held to it. The parts in between were bounded
one request at a time and never added up, so a client could declare one
byte and then stream parts: ten thousand part numbers at twice a 20 MB
part is about 400 GB, per session, and the number of sessions was not
bounded either. None of it counted against anything, because nothing
becomes a File row until the upload completes and ClientStorageUsage sums
File rows. A client with a 1 MB quota could fill the volume and repeat.

putPart()'s own comment described this defect and treated the per-part cap
as the answer to it: "without a cap here the exposure is a day's worth of
disk". A cap on one request bounds one request. The exposure was a day's
worth of disk multiplied by however many requests somebody cared to make.

Three limits, and each one exists because the other two do not cover it.

A session may not stage more than it declared. The room for a part is
claimed before the body is read — a body's length is not known until it
has arrived, and by then it is on the disk being protected — and the write
is then capped at exactly what was claimed, so an over-long body is cut
off mid-stream as it always was, against a smaller number. The claim is a
read and a conditional update under a per-session lock, the same shape
complete() already uses: the protocol sends parts in parallel and how many
is the client's choice, so an unlocked read lets every part in flight
claim the same room, while an atomic claim alone refuses the honest
parallel upload instead. Whatever the part really weighs is settled back
afterwards, in a finally, or a client's own retries would exhaust a
session with room to spare.

Open sessions count against the quota at the size they declared. A quota
measured against finished files alone is spent twice by opening sessions
one after another — each is told there is room, because the ones before it
have not finished. The cost is that an abandoned transfer holds its share
until it is cancelled or swept, so the sweeper now runs hourly rather than
daily: that gap is now somebody unable to upload, which it was not before.

And a cap on open sessions, because for anyone with no quota to spend —
staff, and clients on an installation that sets none — the session count
is the only thing between a declared size and any multiple of it.

Four tests fail on the unfixed code, and three existing ones had to change:
they declared a tiny size and sent a large part deliberately, to reach the
re-checks at complete(). That route is now closed at putPart(), so they
reach those re-checks the way a real install would instead — the file-size
limit or the quota moving while a long transfer is running, which is the
reason complete() re-asks rather than trusting what store() decided.

The staged-byte total is BIGINT UNSIGNED, and the suite runs SQLite, which
has no unsigned integers. The first version of the bounds read
`staged_bytes + :delta BETWEEN 0 AND size` and raised SQLSTATE 22003 on
MySQL for any refund — in the comparison, so the bound written to prevent
the underflow was the statement that underflowed. Every SQLite test passed
on it. Both bounds are now arranged so the column is never inside a
subtraction, and UploadSessionStagedBytesMysqlTest skips loudly unless the
connection is MySQL. Verified against 8.4, as was the report itself: three
sessions declaring one byte each put 6 MB on the volume of a client with a
1 MB quota before, and nothing at all after.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CNFU55Tkq6MuEQ73nbbBRx
 2026-09-11 12:05:41 -03:00
ignacionelson 83a8fe2288 Claim the installation instead of checking whether it is free 
Reported by @ry2811 as GHSA-w3w9-prpw-qx77, with a working two-worker
reproducer.

Setup asked the database whether any staff user existed, and created one
some time later, in a separate statement with nothing joining the two. So
two POSTs arriving together both read "no staff" and both inserted a System
Administrator. Different addresses do not collide; `users.email` is the only
unique key and it has nothing to say about there being one first
administrator.

The gap is not narrow. Between the check and the insert sits password
hashing at BCRYPT_ROUNDS=12, which is slow on purpose, so the window is
hundreds of milliseconds wide and observable without trying.

What makes this worth fixing is not that a stranger can set up an
unconfigured installation — first-run setup is open to whoever reaches it
first, and always was. It is that racing the operator is *quiet*. The
operator's own request also succeeds, also redirects to /setup/success, and
the installation they get looks exactly like the one they expected. The
second administrator is discovered later or not at all, and closing setup
afterwards does not revoke it.

FirstAdministrator::claim() makes it one operation. The row it locks is the
System Administrator role, because the obvious candidate cannot work: there
are no staff rows on a fresh install and a lock over an empty result
serialises nothing. That role row is written by the roles migration and
rewritten on every boot, so it is always there to be locked. The second
caller waits on it, and by the time it has the lock the first caller's user
is committed and visible to the re-check it then makes.

Everything the request writes moved inside the claim, including the site
name. A request that loses now writes nothing at all, rather than renaming
the installation on its way to the login screen.

`projectsend:admin --if-none` had the same shape and is fixed the same way
— two containers coming up against one database is the version of this that
needs no attacker. The early check stays where it is so an unattended boot
does not prompt for a password it is about to discard; it is simply asked
again under the lock.

Both tests fail on the unfixed code. They stage the interleaving rather than
attempting real concurrency, creating the winning administrator from a query
listener after the request has made its first check — which is exactly the
window, and the re-check is the only thing that closes it. The lock itself
is invisible to them: the suite runs SQLite, where lockForUpdate() compiles
to nothing. That half was verified against MySQL 8.4 by running the
reporter's race for real, two processes through the full HTTP kernel: two
administrators before, one after, repeatably.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CNFU55Tkq6MuEQ73nbbBRx
 2026-09-11 11:34:26 -03:00
ignacionelson 62c763d04e Put a floor under a client quota nobody set 
Setting::DefaultClientStorageQuotaMb defaults to 0, and 0 means
unlimited. That is the right default for somebody setting up their own
installation and the wrong one for an installation a platform operates
on other people's behalf: an account that arrived without an explicit
quota has no ceiling at all, and it does not have to be an account the
platform created.

So a platform may set a floor in the environment
(PROJECTSEND_PLATFORM_DEFAULT_CLIENT_QUOTA_MB), exactly as it sets the
seat caps, and for the same reason those are not settings: it is the
shape of what was sold rather than a preference the installation's
administrator is expressing. It applies only where the setting says
nothing, so an administrator who chose a number keeps it, and an install
with no platform behind it is unaffected.

ClientStorageUsage::defaultQuotaMb() is where the three sources resolve,
and every screen that presents the answer now reads it there:

  - The client create and edit screens. The edit screen mirrors that
    resolution client-side to draw the usage bar, so handed the raw
    setting on a floored installation it computed an effective quota of
    zero, printed "unlimited" and hid the bar entirely -- for a client
    whose next upload was about to be rejected for exceeding a limit the
    screen said did not exist.

  - projectsend:status, which gains clients_can_register and
    default_client_storage_quota_mb. Both defaults are the permissive
    ones, both are invisible from outside, and a document reporting the
    setting while uploads obeyed the floor would say the ceiling was
    missing on an installation that has one.

The Client settings form deliberately still reads the raw setting: that
field is read and written back on save, so prefilling it with the floor
would write the platform's number into the setting as the
administrator's own choice, where it would outlive the floor.
 2026-09-11 00:41:31 -03:00
ignacionelson 0671848bfa Read settings written before the columns they name existed 
Reported by @apps3000 in #1770. Upgrading a container from 2.0 or 2.1
with external storage configured restart-loops, and says the database is
unreachable while the database is fine.

A row hydrated from the database does not get the model's column
defaults — only a new model does. So a row written before
external_storage_settings.provider existed reads that column as null,
and the enum match in isConfigured() throws UnhandledMatchError.

That would be a small bug anywhere else. It is not here, because
PlatformServiceProvider::boot() reads these settings on every process
boot, and boot happens before `artisan migrate` runs. During an upgrade
the code is new and the schema is still old, so every artisan command in
that window dies — including `projectsend:update`, the one that would
have added the column. Reordering the entrypoint or using a lighter
readiness probe does not help for that reason; the crash is in the
bootstrap, not in the probe.

current() now applies the model's declared defaults to any column the
hydrated row does not have. That closes the window for every column with
a default rather than for the one where it was found, and goes inert the
moment the schema is current. The match in isConfigured() is left total
on purpose: a default arm would swallow a real unhandled case, and the
invariant it needs now holds at the one place the row is read.

The probe's message is the other half. It boots the whole application,
so it fails both when the database is absent and when the application
cannot start, and it reported the second as the first — sending an
operator off checking credentials that were never wrong. It now prints
the error it actually hit and says which of the two it looks like.

Verified end to end against a 2.1-shaped database: `artisan migrate`
dies with UnhandledMatchError before the change and completes after it,
leaving the row reading as S3 with its bucket intact.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QmyH342d8MuW3pDuE9mbtS
 2026-09-10 17:23:26 -03:00
Ignacio Nelson 469297893b Merge pull request #1775 from projectsend/s3-instance-role 
Support AWS IAM roles for S3 storage
 2026-09-10 16:38:50 -03:00
ignacionelson eaba7ff633 Let an AWS-hosted install authenticate as its own IAM role 
Requested by @ToMMy86 in #1773: an install running on ECS, EC2 or EKS
already has a role attached, and making it also create an IAM user with
a long-lived access key is both extra work and a worse security posture
than the one AWS offers.

The AWS SDK resolves credentials from its default provider chain
whenever none is supplied, and Laravel's FilesystemManager already omits
the `credentials` entry when the key and secret are empty — so the
upload path needed almost nothing. What blocked it was ours:

- `isConfigured()` demanded a key and a secret for S3, so a
  credential-less row was never "configured" and every upload silently
  stayed on the local disk.
- `access_key` was `required_if:provider,s3` on both the save and the
  connection test.
- `probeS3()` built an explicit `credentials` array, so Test connection
  would have failed even once uploads worked.

An explicit `use_instance_role` column rather than "the key was left
blank", because blank already means "keep the credential you have" on
this form — neither the secret nor the GCS key file is ever sent back to
the browser. Ticking it deletes the stored key and secret rather than
leaving them in the row for the next database dump.

Unchanged for everyone else: MinIO, Backblaze, Wasabi and any other
S3-compatible service still authenticate with a key and secret, and the
region is still required — the chain resolves credentials, not regions.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QmyH342d8MuW3pDuE9mbtS
 2026-09-10 16:16:31 -03:00
ignacionelson 6339ae1514 Answer a failed reset the same way whatever failed 
The screen leaked account existence a second way, through the write, and
this one is older than last night's: it is the scaffolding. Laravel
answers a failed reset with passwords.user for an address it cannot find
and passwords.token for a real one whose token is dead, and the controller
surfaced __($status) straight through. Two sentences, one difference, and
the difference is whether the account is here.

passwords.throttled is the third and the sharpest. The broker throttles
per user, so an address nobody holds can never be throttled — being told
to wait is being told the account exists.

All of them collapse to one sentence now. Nothing is lost: the action is
the same in every case, and /forgot-password one step earlier already
refuses to say whether an address has an account. Keeping three messages
was only ever more precise about a thing we had decided not to say.

Found because the portal session went looking for the GET oracle I had
just fixed, found theirs, and also found a POST variant I had not thought
to check. I had it too.

The test asserts the two refusals are identical rather than naming the
sentence, so it survives the wording changing.
 2026-09-09 08:04:54 -03:00
ignacionelson 7c4b582d25 Stop the expired-link notice saying whether an account exists 
I built the oracle in the commit whose docblock describes preventing it.
The comment said a page answering "expired" for a real address and
something else for an unknown one would tell anybody who typed a guess
whether an account is here — and then the method returned false for an
unknown address and true for a known one. Two branches, two answers, and
the difference was the account.

/forgot-password deliberately says "a link will be sent if the account
exists". This undid that on the next screen along.

Both branches answer the same now: anything that will not validate reads
as expired, whether the address is known, unknown or absent. The message
stays right in every case somebody real will meet — a mistyped address
gets "ask for a new link", which is what they should do anyway — and the
page reveals nothing.

The test is written as "these two are the same answer" rather than "both
are false", so it keeps holding if somebody later changes which answer it
is. The two tests that encoded the oracle asserted `expired` was false for
an unknown address; they were pinning the bug.

Found by asking my own question of my own code. The portal session had
checked whether their collation folded addresses, which sent me back to
the reset screen to see what it does with an address it cannot place.
 2026-09-09 07:53:30 -03:00
ignacionelson b96d060ad8 Compare an address ourselves, instead of asking the collation 
Reported by @choewonwoo1817 as GHSA-wgxf-v8cr-37mj, with a working
end-to-end reproducer against Keycloak.

`where('email', $address)` is not an exact match. It is whatever the
database says equality means, and the collation INSTALL.md tells people to
create — utf8mb4_unicode_ci — folds accents:

    administrator@example.com = administrator@éxample.com   -> 1

Those are two different domains. The second is xn--xample-9ua.com, which
somebody else can register and honestly verify at an OIDC provider. So an
attacker with no account here could sign in as themselves and be handed
the first account: SocialAuthenticator found it, linked their subject to
it permanently, and started a session. No password, no interaction from
the owner, an administrator session where that account was one.

Comparison now happens in PHP, in one place, on every driver. Case is
still folded because that is a real requirement — addresses are stored
lowercased and a provider may send any case — and mb_strtolower folds case
without folding accents, which is exactly the line to draw.

Three call sites move to it and two deliberately do not. Loose matching is
right when *refusing* and wrong when *selecting*: AvailableEmailRule and
ClientProvisioning ask "is this address free", where a collation that says
no to a near-miss refuses more registrations, which is the safe direction.
The three that ask "which account is this" are the social path, the login
form (where a password still gated it, so it was confusion rather than
takeover) and the erasure command (irreversible, and the wrong row is the
wrong person).

The test story is the part worth reading. The suite runs on SQLite, whose
`=` is byte-exact, so this defect does not exist there and never did —
which is how it survived six releases with everything green. A test
written the obvious way passes on unfixed code. So the comparison is
pinned by driver-independent tests that always run, and the chain is
proved by AccountLookupCollationTest, which skips unless the connection is
MySQL and carries the command to run it. Run against real MySQL with the
real collation: it fails on the old code and passes on the new.
 2026-09-09 07:32:26 -03:00
ignacionelson 6d7d80f62f Give the announcement band its own row, and put it on the dashboard too 
All four themes had it as a flex child of the row holding the heading and
the buttons, so it was never full width: it took part of the line and
squeezed "My files" and "Upload a file" into a narrow column beside it. It
now sits above that row, which is where the staff dashboard has always put
it and where the comment claimed it was.

Worth noting why four themes shipped it wrong. The band renders nothing
for almost every viewer — it needs a hosted instance, a free plan, and a
client looking — so the broken layout was invisible to the suite, to the
build, and to anybody working on those pages. Seen only once somebody on
the real free tier looked at it.

Also adds it to the client's dashboard. That screen is about the account
rather than about the files, which is the more natural place for an offer
about the plan, and both read the same shared prop so they cannot disagree
about what is said or to whom.

Checked with real screenshots in all four themes and on the dashboard,
against a temporary listener standing in for cloud-modules, since this
install is community and would otherwise render nothing. The listener and
the theme setting were both put back.
 2026-09-09 01:04:15 -03:00
ignacionelson bc559ade3f Prove a client's upload announces itself, not just a staff one 
The test above this said "whichever path stored it" and only exercised
the plain staff POST. The path the hosted free tier hangs on is the other
one: a client, through the resumable flow, whose upload is what
cloud-modules listens for to mint the public link.

Worth its own test rather than trusting the shared StoreUploadedFile,
because the package's suite structurally cannot tell us. It fakes both the
event and the link-minting, so a chunked path that stopped dispatching
would leave all 140 of its tests green and the free tier silently inert on
a real instance. That gap is why the listener was checked against
sim-cloud by hand rather than believed; this is the half of it that
belongs in core and runs on every commit.

The counter-check is worth a note. The first attempt at it changed
nothing — `\$file` inside a sed pattern is a literal, so the substitution
never matched and all six tests passed, which reads exactly like a fix
that is not load-bearing. Confirmed the mutation landed by counting the
line before re-running: three tests fail without the dispatch, the new one
among them.
 2026-09-08 21:12:50 -03:00
ignacionelson df44c46a12 Say a reset link has expired before asking for the work 
The page rendered the form without looking at the token, so somebody
opening a link an hour late typed a password, typed it again to confirm,
and was then told "this password reset token is invalid" — a word nobody
outside the code knows, at the end rather than the start. Links last an
hour and people open them late. That is ordinary, not an error to be
scolded for.

store() still validates and is still the rule; there is a test that a
spent token is refused there whatever the page drew. This is only the
screen being honest a minute earlier.

An address that is missing, or belongs to nobody, is drawn as the form was
before. Partly because an unanswerable question is not an expired link,
but mostly because a page that said "expired" for a real address and
something else for an unknown one would answer whether an account exists
here to anybody typing guesses — the exact property /forgot-password
protects by saying "a link will be sent if the account exists". Two tests
pin that.

Worth having now rather than later: the advisories publishing with this
release will send more people than usual through this screen, in a hurry
and some of them frightened.

Found by the portal session's user, who opened a real link an hour and
forty minutes after it was sent.
 2026-09-08 20:08:28 -03:00
ignacionelson a1f59e133b Translate the strings the security fixes added 
Three, sixteen locales: the Entra optional-claim instruction on the
social-login screen, and the two the profile screen gained when changing
an address started asking for a password.

The catalogues gate the release build, so these had to land before the
version could be stamped.
 2026-09-08 19:59:31 -03:00
ignacionelson 0a3410140d Keep an erased staff member's library away from a client 
The reassignment target is one installation-wide id used for every
erasure, and the picker offers clients deliberately: erasing a client and
handing their files to another client is what the setting is for.

Applied to a staff account the same id means something else. A staff
library is usually the whole installation's, so a client named there
inherits all of it — through an unattended scheduled job, with no
per-account confirmation, because this is the default rather than a choice
somebody makes at the moment of deleting.

So a staff account's content may only go to staff. With nobody valid to
hand it to, handleContent() already cascades, which keeps the existing
promise that content is never orphaned — it now also never becomes a
disclosure.

Not in the settings validation, which is where it looks like it belongs.
That runs when the target is chosen, and whose account will be erased
later is not knowable then. Both halves are only in hand here.

Found while checking a list from the portal session, who had it as one
where() on `type`. That would have been too broad: it would also have
stopped a client's files reaching another client, which is the case the
setting exists to serve. The condition is on the account being erased,
not on the target alone.
 2026-09-08 19:36:48 -03:00
ignacionelson 80cf99d80e Put what the operator must do at the top, and mark it 
The upgrade notes sat at the bottom of a release entry, after every list
of what changed. That is the wrong end of the page: somebody deciding
whether to upgrade reads the first screen and stops, and that is exactly
the reader who needs to know a permission stopped working or a value
changed meaning.

So the section moves to the top of the entry, gets a heading nobody
skims past, and opens by saying what these items have in common —
everything else in a release happens on its own, and these do not. It also
says plainly that none of them stops the upgrade, because an operator who
cannot tell "the installation will not start" from "one role gets a 403"
plans the wrong maintenance window.

Three items for this release: the CAPTCHA flag that now means the
opposite for anybody who typed something other than true or 1, the public
folder permission that is now asked of staff, and the Entra claim.

Releases before this keep the old "Upgrade notes" heading — rewriting
published entries would change what people were told at the time. The
file's own header names both, and the release skill now carries the new
shape so the next one does not drift back.
 2026-09-08 19:15:10 -03:00
ignacionelson cbc6760a93 Warn that a mistyped CAPTCHA flag now means the opposite 
The fix reads only true and 1 as "disabled". An operator who wrote
"off" and has been running without a CAPTCHA gets it back on this
upgrade, which is correct and is still a surprise if nobody says so.
 2026-09-08 19:10:13 -03:00
ignacionelson d8ca41ae0c Credit the reporters by their GitHub handles 
One of the four said 'the same researcher as the group finding above',
which was wrong: @skeletonsec reported the public-folder and upload-target
findings, @Drescargot the group one. The other two were credited by name
rather than by handle, which is not how anybody finds them.
 2026-09-08 19:08:27 -03:00
ignacionelson 1149df277b Ask for the public-folder key before publishing through a folder 
Reported as GHSA-237r-jx85-j3hr.

A file is public if its own flag is on or its folder's is, so the upload
destination reaches the property `upload_public` guards without touching
the switch. A staff member allowed to upload but deliberately not allowed
to publish could publish to the anonymous public site by choosing where
the file landed.

No new key. `upload_to_public_folders` already exists, already appears on
every role's checkboxes, and already means exactly this on the client
branch of the same method — MyFilesController's picker calls it the
established meaning of the two keys. It was never asked of staff, so on a
staff role that checkbox did nothing at all: an unenforced permission, the
class this project audited and closed once already.

Effectively public rather than the folder's own flag, because the flag is
inherited down a subtree: a private folder inside a public one publishes
just the same, and a check on the folder's own column walks past it. There
is a test for that case specifically.

One place, because every upload path — the plain POST, the chunked flow,
the API and the client portal — already asks Folder::uploadableBy(). The
sibling report about the target folder not being scope-checked at all
(GHSA-56qr-cq56-qg66) was fixed in 2c2b86ff and is what put the scope
check on the line above this one.
 2026-09-08 19:05:53 -03:00
ignacionelson ab5fa2da8b Make Entra prove the address, not just the directory 
Reported by Dickson Massawe as GHSA-2rfh-v3j2-2jg7.

Pinning the tenant was half an answer. It defeats the classic
cross-tenant nOAuth, where a stranger's own directory asserts your
address, because a foreign tenant carries a different tid. It does
nothing about the same attack from inside the pinned tenant: Entra's
email claim is user-mutable — a B2B guest's otherMails among its sources
— so a colleague or an invited guest could present an administrator's
address and have their subject bound to that account.

Tenant-pinning answers "which directory said this". It never answered
"does this person own that address". xms_edov is Microsoft's own answer
to the second, and their guidance says to require it wherever email
identifies an account. Absent counts as unverified, which is the only
safe reading given it is absent by default.

Nobody is locked out by this, which is worth saying because it looked
like a breaking change until I read SocialAuthenticator::resolve in
order. An account already linked resolves by subject at step 3, before
trust is consulted at all — those keep working untouched. A first-time
link to an existing account is refused with the message that already
exists for exactly this case, which names the way through: sign in with
your password and connect the provider from your settings. A brand-new
account is still created; it goes to the approval queue rather than
auto-approving.

The settings screen and docs/testing-social-login.md now tell an
operator to add the claim, and there is an upgrade note.

The tests exercise fromSocialite() on raw claims, which nothing did
before: tests/Feature/Auth/SocialLoginTest.php builds a SocialIdentity by
hand and so never reaches this mapping. That is how the branch could
trust a tenant match alone with a full suite passing.
 2026-09-08 19:00:46 -03:00
ignacionelson 3244be6bac Ask for the password before changing the address a reset goes to 
Reported by Nooraldden Khalel as GHSA-f32x-fgmp-q353.

The profile screen let a signed-in session change its own email address
with nothing else, and that address is where a password reset is sent. So
a stolen session was enough: point the account at your own inbox, ask for
a reset, set a password, and temporary access is permanent ownership.
Clearing email_verified_at did not stand in the way, because the model
does not implement MustVerifyEmail and the reset broker never asks.

destroy(), thirty lines further down the same controller, has always
required the current password, and its comment says why: "the rule every
other door into this already asks". This door leads to the same place and
was not asking.

Only a *different* address asks. A name, a timezone or a custom field is
not a credential, so the rest of the screen saves with nothing extra —
which is why the rule is excluded rather than flat, and why the comparison
is trimmed and lowercased: re-saving a profile with the address typed in a
different case must not demand a password for nothing.

An account whose credentials live in a directory or at an identity
provider is refused outright and told why, rather than being asked for a
password it does not have. LdapProvisioner stores Str::password(64)
exactly so that local password can never be used, so asking would be a
dead end dressed as a form error — and the address is not theirs to change
here anyway: it is what the directory says it is.

The test walks the whole chain rather than checking the field is
validated, because the chain is what made this high: change the address,
ask for a reset there, and confirm nothing is sent and no such account
exists.
 2026-09-08 18:57:01 -03:00
ignacionelson 5fb17388cd Stop scoped staff reaching groups that are not theirs 
Reported by @Drescargot as GHSA-r3hg-3fxw-rcmr, in two halves.

The groups listing never narrowed at all. Every other action in that
controller is guarded with allowsGroupChange(), and index() — web and API
alike — built a bare Group::query(), so a client-scoped staff member was
shown every group on the installation with its name, description and
member count. StaffLibraryScope::groups() is that narrowing, and
assignableGroupIds() now reads from it rather than restating the same
rule a second time, which is how the two drifted apart to begin with.

The second half is the one that mattered. allowsGroupChange() asked only
groupReachesNoFurther() — "is anything shared with this group outside my
library" — which a group with nothing shared with it yet passes
vacuously. So a scoped staff member could rename, delete or publish a
group whose every member was somebody else's client. Publishing is the
sharp end: whatever is shared with the group afterwards is reachable
without signing in.

The reporter suggested putting the membership check inside
groupReachesNoFurther(). Tried, and it breaks two things. That predicate
is shared with allowsGroupMembership(), where a group nobody has joined
must stay usable so its creator can add the first member. And "every
member must be mine" is the obvious reading of the rule and is wrong: it
turns GHSA-whmp-p9hv-r7j7's narrowing — a mixed group's edit screen
loads and simply does not name the stranger — back into a 404, undoing
that fix. Four tests from it fail that way.

So the check sits in allowsGroupChange() alone, and asks whether the
group is wholly somebody else's rather than whether it is wholly theirs.
A mixed group stays workable and is still covered by the reach check; an
empty one stays nameable by whoever just made it; a group with members
and none of them theirs is refused.
 2026-09-08 18:40:33 -03:00
ignacionelson 2be423d685 Translate the download counts and the copy-link control 
Four strings, sixteen locales. Everything else was already complete, so
this is the whole of the debt from the client-portal work.

Czech, Polish and Russian do not get "downloaded :count times": those
languages inflect the noun according to the number in front of it, so no
single string can be right for every value. They read as a labelled count
instead — "Pobrania: :count — ostatnie :date" — which is the shape the
other numeric strings in those catalogues already use.

German and Turkish stay formal, Spanish, Dutch, Polish and Chinese stay
informal, as the rest of each catalogue does.
 2026-09-08 18:22:25 -03:00
ignacionelson 6560346280 Mark the first administrator's address verified, as intended 
The last two paths that passed email_verified_at into User::create() and
lost it: the setup screen, and projectsend:admin for a container that
comes up from environment variables. It is deliberately absent from
$fillable, so mass assignment drops it without a word, and both meant to
set it.

The intent is plain in both cases — the first administrator typed their
own address into the form in front of them, and whoever provisioned the
container supplied it themselves. There is nobody to confirm it to.

Inert today, since MustVerifyEmail is not enabled on the model, but the
column is what a later switch would read: turning verification on would
have locked out the one account that cannot be helped by another
administrator.

Both are now pinned by a test that fails when the forceFill is removed.
StaffAccounts had already fixed this for staff and named the rest; with
client accounts done earlier today, that list is empty.

Also says on User::$fillable what absence from it buys and what it does
not. It stops a request smuggling a value in; it does not tell code that
meant to set the value that it failed. Four separate paths made the same
mistake against the same comment.
 2026-09-08 17:07:35 -03:00
ignacionelson e187513cdd Stop a mistyped CAPTCHA flag from switching the CAPTCHA off 
`env()` recognises the words "true" and "false" and returns everything
else as the string it was — and every non-empty string is truthy in PHP.
So `(bool) env('PROJECTSEND_CAPTCHA_DISABLED')` read all of these as "yes,
disabled":

    PROJECTSEND_CAPTCHA_DISABLED=no
    PROJECTSEND_CAPTCHA_DISABLED=off
    PROJECTSEND_CAPTCHA_DISABLED=fasle

An operator who meant to say no took the bot protection off their login
and registration forms and had nothing to tell them so — the setting
screen still shows the CAPTCHA configured, because this is the escape
hatch that runs ahead of it.

For most settings the cast is a shrug: somebody notices the feature is on
and fixes the line. It stops being a shrug when the wrong answer is the
unsafe one, and this is one of those. EnvFlag lists what counts as yes —
`true` and `1`, either case, either type — and reads everything else,
recognised or not, as no. A value typed as `disabled` turns nothing off:
a configuration mistake to be found rather than guessed at.

Found while fixing the same bug in a new cloud-modules flag, where the
unsafe direction was publishing a customer's files rather than dropping a
CAPTCHA. Two of the four remaining `(bool) env()` casts are left alone on
purpose: a wrong S3 path-style value breaks storage loudly, and the
migration tool's direct mode defaults to true anyway, so neither fails
into an unsafe state.
 2026-09-08 17:05:30 -03:00
ignacionelson 896675d631 Tell a client whether their own file arrived 
"Did it arrive?" is the question somebody asks about a file they sent, and
on a hosted free account — where a link is the whole of the sharing — the
count is the only evidence either way. Every file a client uploaded now
shows how often it has gone out and when it last did, in every render mode
of every theme.

Only their own. A download entry says somebody fetched the file, so a
count on a file shared with several clients tells each of them about the
others' activity, and nobody is entitled to that but the person who put
the file there. A file shared *with* this client carries null, not zero:
a zero would itself be a claim, and the two have to be distinguishable
because zero is an answer the owner came looking for and is shown as
words.

Counted from the activity log through the same three actions
DownloadAllowance uses, so a file leaving by the public site counts as
much as one leaving by its link. One query for a listing, none at all for
a client with no files of their own. Both filters have a test that fails
when only that filter is removed.

Two things a render check caught that types and a green build did not.
`t()` does no plural selection — the catalogues are flat key/value — so a
"one|many" string reached the screen with its pipe intact; the strings are
whole sentences now, with the singular spelled out. And the gallery card
was already laying its text out beside the action icons in a 200px column,
truncating the filename to "Q…" and the size to "75 …" on main today;
stacking them gives every line its full width.
 2026-09-08 16:56:54 -03:00
ignacionelson 92bb807849 Show a client the public link to their own file 
A client's portal lists two kinds of file side by side: what they
uploaded, and what somebody shared with them. Where a link exists on one
of their own, they can now copy it from the row — which is what makes the
hosted free plan a product rather than a place to put files, since a
customer there has no staff screen on which to make one.

The rule is narrow, and both halves are load-bearing: a link this client
created, on a file this client uploaded.

Not "a link on a file shared with them" — that link is the sharer's
decision about who may reach the file, and handing the recipient the URL
would quietly turn "you may download this" into "you may pass this on to
anyone".

And not "any link on their own file" either — a link staff minted on a
file a client uploaded exists for a reason the client may be no part of,
and on the shared instance it would sit beside the one link they were
promised. Ordering is by id, so an unfiltered lookup would hand them
whichever was minted first.

Both halves have a test that fails when only that half is removed. The
first draft did not: every case was carried by the ownership filter
alone, so the creator check was green for the wrong reason.

Links that no longer work are left out rather than shown greyed. The only
thing a client can do here is copy it, and a URL that answers "this link
has expired" is worse than no URL at all.

One query per listing, not one per row, and none at all for a client with
no files of their own.
 2026-09-08 16:47:57 -03:00
ignacionelson 0a28e239d6 One home for what a client account is 
Three surfaces create client accounts now: the staff screens,
/api/v1/clients, and the platform control plane in the private package.
Two of them held their own copy of the type, the role, the active flag,
the "0 means inherit the site default" quota, the verified stamp, the
activity entry and the seat guard — and the third could not have a copy
at all, because a package cannot import a host class.

ClientAccounts is that one definition, reached by name from outside.
What stays with each caller is what genuinely differs: its validation,
its response, its custom fields, and who is asking.

Two things changed rather than moved:

The seat cap is now checked inside create(), before anything is written,
instead of at the top of each controller. That is what makes a leaked
platform token an incident rather than an unbounded one — a guard that
ran only where somebody remembered it is not a guard.

email_verified_at is written with forceFill. It is deliberately absent
from User::$fillable, so every client-creation path passed it into a mass
assignment and lost it in silence. StaffAccounts already noted this and
named the other paths; this closes the client half.
 2026-09-08 16:23:34 -03:00
ignacionelson 3d923188d9 Show an announcement on the client's own file portal 
The band existed only on the staff dashboard, which is a screen a client
never opens. On a shared instance the customer *is* a client account —
they sign in, upload, and share by link, and the administrator is the
operator — so a message for them has to reach the page they actually use.

ViewerAnnouncement reads the shared prop itself rather than taking one,
so each theme adds it in a single line without threading a prop through a
page that has no other reason to know about it. All four portal themes
render it, because a message that only appears in the theme somebody
remembered to wire is a message that quietly does not exist.

Above the heading, not inside the list: it is not one of the things the
client came to do, and burying it under the files would defeat the point
of having it at all.

No theme decides who sees it. Core drops anything not aimed at the
viewer, so a theme renders whatever it is handed and cannot leak a staff
message to a client by being careless.
 2026-09-08 15:55:47 -03:00
ignacionelson b128b114b5 Make an announcement say who it is for 
The first version refused clients outright. That was right for the only
message that existed — a hosted instance telling its administrator about
their plan — and it stopped being right the moment a message needed to
reach the *clients* of a shared instance, where the administrator is the
operator and the customers are client accounts.

The unsafe fix would have been to drop the guard and let each listener
check `isStaff`. The safe one is to make every caller say who it is
talking to and have core enforce it: `show()` now takes a required
`audience` with no default, and a message aimed elsewhere is dropped
before it reaches the props. A listener that forgets therefore reaches
nobody rather than everybody, which is the direction a mistake should
fall.

An unrecognised audience reaches nobody either, and is ignored rather
than thrown — a listener aimed at the wrong people should show nothing,
not break the page it was decorating.

The old "a client is never shown one" test became "a message for staff
reaches no client, even from a listener that never checks", which is the
property that actually matters and the one the enforcement provides. Two
more pin the other directions: a client message reaches clients and no
staff, and an unknown audience reaches neither.

cloud-modules declares `staff` for the free-plan band, and its test fake
enforces the same rule, so a listener aimed at the wrong audience fails
in the package's own suite rather than passing there and misbehaving in
the host.
 2026-09-08 15:48:29 -03:00
ignacionelson 757fba19ca Give uploads a seam, and link-minting one home 
Two pieces of groundwork, no behaviour change.

FileWasStored is dispatched from StoreUploadedFile, which every upload
path converges on — the chunked flow staff and clients share, and the
synchronous POST beside it. A listener therefore sees each upload once
without knowing which route produced it, which is the property that makes
it usable from outside this repository. A notification, not a filter:
nothing on it is mutable, and anything that needs to influence an upload
has to do so before the bytes land, which is what ResolvingUploadDisk is
already for.

CreateShareLink is the other half. Minting a link was a ShareLinksController
private concern, and the controller is an HTTP handler behind `staff`
middleware — so a link now needs making from outside a request as well.
Two copies of "make a token, write the row, log it" would drift, and the
half most likely to drift is the token, which is the entire authorization
for /s/{token}: there is no session behind it and no second factor, so
being unguessable is its only defence. Anything minted through the action
gets Str::random(32) — about 190 bits, more than a UUID's 122 — and never
a chosen value. The chosen-token path stays in the controller, where a
person is typing one into a form and its minimum length can be argued
about in a validation rule.

The permission questions stay in the controller too. Whether somebody may
set an expiry or a download cap is a fact about them, and the action has
no viewer to ask; it takes both already resolved, including the expiry,
because "the end of the 12th" depends on whose timezone you are in.

Five tests, including that the file a listener receives is complete and
readable rather than half-built, and that the staff form still refuses an
expiry to somebody without the permission after the extraction.
 2026-09-08 15:39:55 -03:00
ignacionelson 763e7b0e2e Render one image once, however many requests ask at the same time 
Renditions are generated on demand and cached by existence, and nothing
between the callers stopped two requests decoding the same image at once.
The atomic rename settled which file survived; it never stopped both from
doing the work. So N concurrent requests for one cold rendition were N
full-size decodes, each holding four bytes per source pixel — up to 160 MB
at the 40-megapixel ceiling.

That is not an attack. A public listing emits a thumbnail URL per file, a
browser opens six or more connections at once, and the first visit to a
gallery of ordinary camera images was six simultaneous decodes on a
container sized for one. PublicGroupsController reaches the generator with
no account at all, so nothing about it required a customer to be signed
in, and the 240/min throttle bounds rate rather than concurrency.

Worse than a crash, it did not resolve itself: a render killed mid-flight
renames nothing, so the cache warmed only by whatever finished before the
kill and the page died again on the next visit.

A lock keyed on the destination path — which already encodes the file, the
audience and the rendition, so two requests collide exactly when they
would have written the same path. The waiter re-reads after acquiring,
which is what turns a wait into a cache hit rather than a second decode of
the same image.

Waiting rather than refusing, because the arithmetic says so: a waiting
request holds an idle worker at about 35 MB, a rendering one holds that
plus the whole source bitmap. Six waiters cost what one renderer costs.

On timeout it refuses instead of rendering anyway. Falling through would
reinstate the pile-on at the moment the system is already struggling, and
one failed thumbnail is a better outcome than a container that dies and
takes the warm cache with it.

The wait is configurable because the right number is a property of the
machine — a small VPS reading a large source off a slow disk wants longer
— and clamped to at least a second, since a stray empty variable would
otherwise make every concurrent request fail instantly, which is the
opposite of the point.

Eight tests. Two go red without the lock, and the clamp is asserted on the
resolved value rather than the clock, because block() measures in whole
seconds and a timing assertion there would be flaky rather than wrong.

Found by the session sizing free-tier containers, from the outside.
 2026-09-08 15:29:20 -03:00
ignacionelson a5496d24cd Stop describe() vouching for a detection it could not make 
`FileDelivery::describe()` from a console returned
`{"method":"php","detected":true}` on every installation, whatever its web
server. detect() reads SERVER_SOFTWARE, which only exists inside a
request, so a console process has nothing to look at and falls to the
`php` default — and `detected: true` then vouched for it.

The value is right for that process and wrong as a statement about the
installation, which is how anybody running it from `artisan tinker` will
read it. Somebody verifying a healthy nginx tenant hit exactly that, spent
an afternoon on it, and only recognised it as an artefact of *where* the
question was asked after reading `nginx -T` in the container.

There is now a third field. `observed` is false only outside a request,
where `method` is a default rather than a finding. Both screens that read
this run in a request and always see true; it exists for whoever asks from
a shell, which is the one place the answer could mislead.

The two web paths are unchanged and were never wrong — `projectsend:status`
does not report delivery at all, so no fleet ever reported this
incorrectly. What was wrong was a confident answer to a question that
could not be answered from where it was asked.

Three tests: a console reading says not observed and still says php,
because php is what that process would actually do; a reading during a
request observes nginx; and a stated method is observed wherever it is
read, since a decision needs nothing detected to be true.

Found by the session verifying the 2.4.0 canary, not by me.
 2026-09-08 10:21:02 -03:00
ignacionelson fba5f30436 Release 2.4.0 2026-09-08 09:33:14 -03:00
ignacionelson 0f66f9030c Cut the unreleased notes down to what an operator needs 
Each entry was three paragraphs explaining itself. Somebody deciding
whether to upgrade reads a list, and a list that takes ten minutes is one
they skim — so the reasoning is gone and the fact is what is left.

What stayed long is Upgrade notes, deliberately: those are the two things
somebody has to *do*, and a one-liner that says "allow headroom" without
saying how much or when is a note they have to come back and ask about.

This makes the section shorter than 2.3.0 and 2.2.1 above it. Those are
published and stay as they are; the style changes from here.
 2026-09-08 09:06:00 -03:00
ignacionelson 7c16733c16 Stop a managed instance being able to hide the project news 
I shipped both daily calls as the same kind of thing — an operator's
preference — and only one of them is. That was wrong in the direction that
matters, because it handed a decision over rather than keeping it.

An update notice on a hosted tenant is useless: they cannot act on it, the
image is ours, and the screen that would show it is closed by capability.
So that check does not run there at all, which is right and unchanged.

News is the reverse. Announcements about the product are exactly what a
hosted customer should be told, and a Cloud client with view_news sees
that card today. One administrator switching it off for everybody on that
instance is not a decision the platform meant to hand over — so on a
managed instance the news now runs whatever any setting says, including a
row left behind by an instance that used to be self-hosted.

Capability::NewsConfigure, Community-only, and the thing it gates is the
*choice* rather than the news. A self-hosted operator keeps the switch,
because there nobody else decides what their installation reaches out for.
An edition difference through the capability registry rather than an
edition check, as everything here is.

Gated in all three places rather than only the screen: the command ignores
the setting without the capability, the controller neither sends nor reads
the field, and the checkbox is absent. There is a test that a hand-crafted
PATCH cannot do what the missing checkbox could not, and the guard is
proved load-bearing — remove it and the managed-instance test goes red.

The changelog and product highlights said "two switches" and now say what
is actually true, including that neither appears on Cloud and why they are
absent for opposite reasons.
 2026-09-08 02:34:00 -03:00
ignacionelson d7d7acce85 Put the announcement behind the header icon too, from one source 
A message worth showing was only on the dashboard, which means somebody
who works in Files and Clients all day never meets it. It now also sits
behind an icon next to the notification bell, and that is on every page.

**One shared prop, not two.** "The same message in both places" is the
requirement, and two props would have drifted the first time anybody
edited one — so the hook moved out of DashboardController into
HandleInertiaRequests, and the dashboard reads the same shared value the
header does. The band and the dropdown also share the component that
renders the words, for the same reason: the reliable way to keep two
renderings identical is not to have two.

Renamed with it. ResolvingDashboardCallout was accurate for about an hour
and became a lie the moment it appeared somewhere else; it is
ResolvingAnnouncement now, and the prop is `announcement`. Free to rename
because nothing has shipped yet — the only other reference was
cloud-modules', by string, updated alongside.

The icon follows UpdateAvailableIcon beside it: absent entirely when there
is nothing to say rather than a dead control, and a plain dot instead of a
count, because there is only ever one of these and a "1" would invite
somebody to look for the second.

Two tests worth naming. One asserts the message reaches a page that is not
the dashboard, which is the whole point of the addition. The other asserts
a client is shown nothing even from a listener that sets it
unconditionally — a client's header carries the bell too, and staff
messages must not reach it however careless the listener.
 2026-09-08 02:17:56 -03:00
ignacionelson 334b11d562 Give packages a way into the sidebar and the top of the dashboard 
Two seams, in the shape docs/extension-points-architecture.md settles on:
a Laravel event with a mutable payload, dispatched unconditionally, and
with nothing listening the documented default holds. A community
installation gets an empty list and a null callout, which is exactly what
it had before.

ResolvingNavigationLinks exists because the sidebar is a hardcoded array
in app-sidebar.tsx, so a package could not contribute to it at all — the
nav entry was a separate manual edit every time a package grew a screen,
and being manual it was forgotten more than once. Staff-only, decided in
HandleInertiaRequests rather than trusted to each listener: these render
in the administration area, and a client's portal shows their own files
and nothing about the installation. There is a test that a listener adding
unconditionally still reaches no client.

ResolvingDashboardCallout is one band above the widget grid rather than a
widget in it. The grid is a closed list of keys that dashboard.tsx renders
one by one and each viewer arranges, so a message that mattered would sit
wherever somebody dragged it, or under a fold, or switched off. One at a
time, first listener wins: a dashboard that can accumulate banners
accumulates them, and the second is what teaches people to skip the first.

Core learns nothing about what either seam carries. Titles, URLs and copy
all arrive from the listener, and that is not fastidiousness — the first
caller is the hosted edition's link to its own customer portal and its
pitch to free instances, which is commercial copy belonging to one
offering and has no business sitting in the public repository because the
sidebar happens to live here.

An external link renders as a plain anchor opening in a new tab, never an
Inertia <Link>: Link expects a page component back and another origin will
not give it one, so it fails without saying so. It is also never marked
active — nothing outside this app is the page you are on.
 2026-09-08 02:07:08 -03:00
ignacionelson da1f432d87 Let an installation stop calling home, two different ways 
Every instance reached projectsend.org twice a day and an operator could
stop neither. The news feed had no switch of any kind — FetchNewsCommand
went straight to the request, touching Settings only to write results back.
The update check had one, but its default is on, and a managed fleet had
been setting PROJECTSEND_CHECK_FOR_UPDATES=false for months against code
that reads no such variable: check_for_updates is a database setting, so
the environment never touched it and updates were enabled fleet-wide the
whole time.

They look like one problem and are two, which is why they are fixed
differently.

**The news feed gets a Setting**, its own key, default on. A Cloud client
with view_news sees that card today — DashboardController gates it on the
permission alone, with a comment saying in as many words that it is both
editions and carries no capability. So switching it off is an operator's
choice rather than an edition's, and it must stay reachable everywhere.
Its own key rather than riding on check_for_updates because they are two
different wants: "do not tell me about releases" and "do not show me the
project's news" are asked separately, and an installation with no outbound
access at all wants both.

**The update check gets a capability guard**, ahead of the setting it
already had, and deliberately not a Setting of its own. On a managed
installation the result is unreachable rather than unwanted: the
dashboard's System card and the update UI are both gated on
Capability::SystemUpdates, which is Community-only, and the image is
chosen by whoever provisioned the instance. A Setting would encode a fact
about the edition as a preference — leaving it switchable back on per
tenant, buying a nightly call for a number no screen can draw, and putting
the reason in a provisioning script rather than beside the code. A
self-hosted install holds the capability and loses nothing: its own
setting still decides.

Both guards return success rather than failure. A scheduled task that was
asked not to run has not failed, and reporting it as one would put a red
line in the scheduler history every night for an installation behaving
exactly as configured.

The news switch is on the General settings screen, outside the
can_manage_updates block that hides the update toggle where the capability
is absent — a setting only reachable by editing a database row is a row,
not a switch. Seven tests, and the two that matter go red when either
guard is removed. Sixteen locales translated in the same commit rather
than left for the pass, since a release is close.
 2026-09-08 01:27:08 -03:00
ignacionelson 82dd475f8f Write up what #1724 and #1733 mean for an operator 
Two entries under Unreleased, both for the same reason: an operator would
otherwise be surprised.

The shorter download link is a behaviour change with a cost attached — a
resumed download more than a minute old is refused where an hour tolerated
it — so it says that plainly rather than only advertising the benefit. It
also says who is not affected, since installations on local disk never used
one of these links at all, and neither do zip bundles.

The upload fix is an ordinary bug fix and would normally need no entry, but
it moves peak temporary disk from "the file plus one part" to "the file
twice over" while assembling. That is a sizing question somebody with a
small temp volume has to answer, so it gets an upgrade note. Nothing to
configure — just headroom.
 2026-09-07 19:25:30 -03:00
ignacionelson b758fca19c Merge pull request #1724 from fix/assemble-keeps-parts-for-retry 
Keep an upload's parts until its bytes are stored
 2026-09-07 19:24:06 -03:00
ignacionelson 02946abf85 Stop the delivery docblock naming nginx as the only local path 
#1733 explains its two lifetimes by contrasting a presigned URL with
X-Accel-Redirect, "nginx serves these bytes, now, to this request". That
was true when the branch was written and stopped being true on 1 September,
when FileDelivery gave the local path four methods — auto, nginx, xsendfile
and PHP streaming.

The argument survives intact: every one of those authorises exactly one
response and nothing that outlives it, which is the property the contrast
rests on. Only the naming was stale, and a docblock that says "nginx" to
an operator running Apache reads as "this does not apply to me".

Found resolving the merge, not by the author — the branch predates the
change it collided with.
 2026-09-07 19:24:00 -03:00
ignacionelson b7ac44e77b Merge pull request #1733 from fix/presigned-download-window 
Give a download's presigned URL a minute rather than an hour

Conflicted against FileDelivery, which landed on main after this branch
was written: main added a constructor where the branch added two
constants. Both belong; the resolution keeps each.
 2026-09-07 19:23:52 -03:00
ignacionelson 50a6a19455 Translate the client file editor into all sixteen locales 
The eight strings the portal file editor added, which had been sitting in
English since the feature landed — the deliberate trade, but the pass is
due now that the English has settled.

Nothing else came up. The scan reports eight missing per locale and they
are all from this feature, so no unrelated drift crept in alongside it.

Written against each catalogue's own established voice rather than
translated fresh: Spanish stays informal, and "Expires on" takes the verb
its neighbouring "Leave empty for a file that never expires" already uses
in each language. Quoting follows each locale too — Russian keeps its
guillemets, Japanese its corner brackets, Chinese and Vietnamese their
curly quotes — matching how the sibling folder-deletion warning already
reads there.

Every :name placeholder survives verbatim, checked rather than assumed,
and the diff is additive: the one deleted line per file is the previous
last entry re-emitted with a comma.

Checked on the screen, not only in the file, which is the part a parsing
JSON cannot show: the editor rendered in Spanish with every label and hint
in place, "Vence el" agreeing with the hint below it, and no console
errors. The dev instance's Client role was snapshotted, granted the keys
for the run, and restored; the throwaway file it needed is gone.

Locale suite green, 13 tests. The 249 orphans each catalogue reports are
older than this work and left alone deliberately — scan.php cannot see a
key held as data or supplied by a package, and a wrongly deleted entry
reverts a screen to English in silence.
 2026-09-07 12:48:10 -03:00
ignacionelson 8de28059db Say when a folder choice publishes the file 
Found reviewing the client file editor rather than building it.

File::isEffectivelyPublic() is "my own flag OR my folder's", and
Folder::uploadableBy() admits a client to a public folder on
upload_to_public_folders — a different key from upload_public. So a client
can make a file world-readable without touching the public switch, and
without holding the key that switch is behind.

That is what those two keys have always meant and what uploading into such
a folder has always done, so this does not refuse it. What was new is
where the choice is made. The upload page is entered from a folder the
client has already navigated to, where the list shows a Globe badge on a
public folder. The editor's picker is a flat list of names, and it is the
first place a destination is chosen with none of that context — so the
consequence was invisible exactly where it mattered most.

Public folders now carry the badge in the picker, and choosing one says in
words that anyone will be able to open the file without signing in. Two
tests: that the side door genuinely publishes and is labelled, and that a
private folder is not labelled — a warning on everything is a warning on
nothing.

The rest of the review found no defect. Ownership, the per-field keys, the
staff-scope trap and mass assignment were already covered; a client
deleting a file that staff later revised was checked directly and moves
the chain's recipients onto the successor without widening them, which is
what it is supposed to do. The write path was driven in a real browser —
rename, publish and delete through the actual form and dialog — because a
green suite over a write that 419s in every browser is a mistake this
repository has made before. Bytes gone, audit trail complete, and
file.made_public records the slug.
 2026-09-07 12:09:27 -03:00
ignacionelson ea214fc27e Give the client portal a file editor 
The authorization landed last commit; this is the way in. A client with
edit_files now gets an Edit action on the files they uploaded, opening a
form with every field their role actually grants, and a Delete beside it.

One page for every theme, not one per theme. portal/edit-file.tsx picks
its shell from the `theme` prop exactly as portal/upload.tsx does, because
a form with eight fields behind five separate permissions, rebuilt four
times, is four places for a field to go quietly missing. What *is*
per-theme is only the entry point: one <FileRowActions /> in each theme's
row actions group, the file twin of the FolderRowActions that was already
there.

Row actions gate on can_update/can_delete, sent per file by
MyFilesController and answered by FilePolicy — never on is_mine, which is
half the question. Holding the file is one half and the role's keys are
the other, and a theme that reads is_mine offers an Edit button that
403s. Written into docs/theming-files-checklist.md so the next theme does
not have to rediscover it.

The folder picker offers only folders the client could have uploaded to,
so it cannot present a destination the save would refuse. Publishing says
in plain words that anyone with the link will be able to open the file
without signing in, and says so differently when the installation has no
public page configured, because there the switch would do nothing visible.

Hiding a control is a courtesy, never the enforcement. Every can_* prop
here is the same question ApplyFileEdits asks when the form posts, and the
tests assert both ends.

Verified in a real browser over CDP rather than only by types and tests,
which say nothing about whether a page mounts: 23 edit actions on the
client's 23 own files and none on the file shared with them, the editor
mounting with its real values, every gated field present, no console
errors. The dev instance's Client role was snapshotted before the run and
restored to exactly what it was.

Refs #1771
 2026-09-07 11:15:22 -03:00
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
ignacionelson 1e30e83f11 Stop projectsend:captcha-off claiming a success it did not have 
The command writes Setting::CaptchaProvider = 'none'. On an installation
using the platform's managed keys, Captcha::resolve() returns
managedConfig() — read from config — before it ever looks at that setting,
so the write lands somewhere nothing reads and every form stays protected.

The command then printed "CAPTCHA is off". That is false in the worst
direction: the person running this is locked out and debugging, and the
message sends them away from the one thing that would have explained why
they are still being challenged.

It now says it changed nothing, and names PROJECTSEND_CAPTCHA_DISABLED,
which is checked ahead of the key source and is therefore the only one of
the two escape hatches that works on a managed installation. The docblock
said those two were equivalent; they never were.

Deliberately not gated behind captcha.configure. Gating it would take a
self-hosted operator's way back in — the alternative being a hand-edited
database row — to close something that on a managed installation does
nothing anyway. Reaching it needs a shell in the container, which needs an
RCE, at which point the CAPTCHA is not the problem.

The command had no test at all. It has three now, including one that pins
the ordering inside resolve(): if the environment check ever moves below
the key source, a locked-out operator loses their last way in.
 2026-09-07 01:24:13 -03:00
ignacionelson d32788e4a1 Put the CAPTCHA settings screen behind a capability 
The screen is open in both editions and stays that way by default, so a
self-hosted installation loses nothing: nobody else supplies its keys, and
nobody else is affected by what it decides.

What the key buys is the ability to take it away. A hosted fleet puts every
tenant on one parent domain and one sending reputation, so an administrator
who turns their own CAPTCHA off is spending everybody else's deliverability
rather than only their own. That is not the shape LDAP and social login
have, which is why those two stay ungated and this one does not.

Gated all-or-nothing on the route, read included, exactly as Storage and
Branding are. Per-field gating in the controller would not have closed it:
switching the CAPTCHA off needs none of the gated fields — `provider: none`
does it, and so does unticking the four per-form switches while leaving good
keys in place — so the PATCH had to be closed too, and the middleware closes
both verbs at once. Which keys the screen may offer is still the separate,
narrower question Capability::CaptchaManagedKeys answers per field.

An operator withdraws it by naming captcha.configure in
PROJECTSEND_CAPABILITIES_DISABLED. Note that the key also joins the list
`projectsend:status` and GET /api/v1/me report, which is additive — the
OpenAPI document types capabilities as an untyped array, so nothing there
needed regenerating.
 2026-09-07 01:20:22 -03:00
Eliana Bracciaforte c3503a0651 Merge pull request #1769 from projectsend/docs/readme-projectsend-cloud 
Name the official hosted version near the top of the README
 2026-09-04 09:22:10 -03:00
Eliana Bracciaforte 51477cbd02 Name the official hosted version near the top of the README 
ProjectSend Cloud already appears in LICENSING.md and CONTRIBUTING.md,
but not in the README — the first thing people and search engines read.
One paragraph after the intro names it, says who runs it, and points to
LICENSING.md for where the line between the free core and Cloud sits.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-09-04 09:19:53 -03:00
ignacionelson 7c9847981a Patch 8 pending security advisories in dependencies 
league/commonmark 2.9.0 -> 2.10.0 fixes an XSS bypass and three DoS
issues; nanoid, qs, brace-expansion, and @humanfs/node bumped via
npm audit fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019iQNYLu5a65foArRdE9zzx
 2026-09-03 11:57:15 -03:00
ignacionelson 7da4635f13 Say which clients a scoped staff member may be told about 
A staff member limited to their own assigned clients could read the names
and ids of clients on nobody's roster but their own, out of ordinary file
metadata.

The file boundary was never wrong. Sharing means a file can legitimately
reach a scoped viewer through client A while client B uploaded it, or
while B also receives it -- StaffLibraryScope::buildFiles is right to
permit that, and a B-only file is still a 403. What was wrong is that
every response then went on to name B. FileResource serialised the loaded
uploader and each assignment unfiltered; ShareTargets::assigned took no
viewer at all, so the details panel published the recipient list as it
stands and forSubject narrowed available_clients while handing
assigned_clients straight through. FoldersController::fileRow,
FilesController::edit, FileDetailsController and ClientFilesController
each named the uploader the same way. The API's uploaded_by filter asked
the question without any name attached: it answered "does this client of
yours put files in front of a client of mine" for any id a caller cared
to try.

12a8ebe3 said the rule out loud while fixing topClientsByStorage -- "the
file was theirs to read and the uploader's name was not theirs to see" --
and then the rule stayed in that widget. So it is a class now.
ClientIdentityScope is the one decision, asked by every surface that
names a client, and it deliberately answers about clients only: a
colleague's name is not a client identity, and hiding it would hide who
uploaded most of the library from the people who work in it. Groups go
through it too, on the same argument -- a group is a list of clients
wearing one name -- which the report did not cover but is the same leak.

Two judgement calls worth naming. assigned() keeps returning the whole
truth and gains a warning, because VisibleCommentScope resolves
notification recipients from it and a recipient filtered out of that list
is one who never hears about a message addressed to them; assignedFor()
is the display half. And FileResource asks at serialisation rather than
in its callers' eager loads, which is the opposite of how the version
counterparts next door are narrowed: that one is set-shaped and folds
into a query, this one is a per-row roster check across eight call sites
in four controllers, two of them re-loading assignments after a write.

The tests assert on whole response bodies rather than on named keys. The
leak was never in one field -- the same name arrived through the
uploader, through the recipient list and through four screens -- so a
body that does not contain the name anywhere is the only assertion that
would have caught all of it. Ten of the eighteen fail without this
change; the rest are the negative controls, including that an unscoped
administrator still sees every name and that the uploaded_by filter still
works for a client on the roster and for staff.

Reported by @Noorkhalel, GHSA-whmp-p9hv-r7j7. Their write-up named every
affected surface and the root cause in each, which is most of why this
took one pass.
 2026-09-03 00:56:41 -03:00
ignacionelson ddf09677f0 Document the branding endpoints where their callers are 
Branding moved into the application on 2026-08-28 and its two read-only
endpoints came with it unchanged -- same paths under
/api/v1/modules/branding, same capability, same ability. Their
documentation did not: the guide still sent readers to
packages/cloud-modules/docs/api.md, so endpoints that every installation
now carries were described in a private repository almost none of their
callers can open.

The OpenAPI document is still not the place for them. OpenApiContractTest
skips api/v1/modules/* on purpose: that document is served
unauthenticated and has to be identical on every installation, while a
module's paths exist only where the module does. So this is a plain
markdown file beside the guide, and published like it -- ignored docs are
maintainer notes, and this one is for integrators.

It is the cloud-modules file moved across, minus the attribution switch:
that half stayed Cloud-only and has no API surface at all. The gate is
described as every edition holding branding.customize, with a hosted plan
able to subtract it, because that is what the enum now says.
 2026-09-02 18:56:55 -03:00
ignacionelson 9b2aea4812 Say what the actions cast actually costs if it goes 
The comment said a reader unmarshalling a map breaks on an empty array.
Checked against the reader since, and it is worse than that: the hosted
platform decodes the block into a typed struct and discards a block it
cannot read, and Go refuses a JSON list into a map outright. A [] here
loses the whole usage block -- downloads and uploads with it -- on the
day a tenant happens to have no counted activity, with nothing logging a
fault. The quietest installations would be the ones that went quiet.

Comment only. The cast was already right; what was missing was the
reason it is load-bearing, which is exactly the kind of condition this
week kept proving nobody had written down.
 2026-09-01 02:05:29 -03:00
ignacionelson 96107fdcd5 Release 2.3.0 2026-09-01 01:18:18 -03:00
ignacionelson eecd5b804d Write the 2.3.0 changelog entry 
Turns the Unreleased section into a numbered entry and adds this
cycle's work to it: downloads on Apache and LiteSpeed, branding in
core, the build fact, the scheduler check, and the run of boundary
fixes.

The three security entries already in Unreleased are carried across
word for word rather than summarised. Their "Who this affected"
paragraphs are the part a reader decides on, and a one-line retelling
would have thrown that away. Their two upgrade notes move across whole
for the same reason, joined by the two this release adds.

Leaves an empty Unreleased scaffold for the next cycle. The version is
not stamped anywhere else yet -- config/projectsend.php and the tag are
still on 2.2.1, so this is the entry waiting for a release rather than
a released one.
 2026-09-01 01:18:08 -03:00
ignacionelson 616aa49867 Translate the download delivery screens into all sixteen locales 
The 29 English strings added by the file-delivery work: the System
widget row and its explanation dialog, and the settings panel that
repeats it.

Product nouns left alone throughout -- PHP, nginx, Apache, LiteSpeed,
X-Sendfile, mod_xsendfile, XSendFilePath, PROJECTSEND_FILE_DELIVERY,
INSTALL.md, S3, Google Cloud. "PHP" as a whole string stays "PHP",
which is why every locale gains one entry counted as untranslated, the
same way API and OK are.

Purely additive: appended rather than merged in sorted position, so each
diff is 29 new lines plus a comma on the line that used to be last.

Verified: scan reports 0 missing in all sixteen, 13 locale tests pass,
and the Spanish settings screen was read out of the running app rather
than out of the file.
 2026-09-01 01:18:08 -03:00
Ignacio Nelson 525c464327 Merge pull request #1740 from denkfabrik-li/fix/update-keeps-cache-signal 
Leave the caches update.sh's own update command needs to see
 2026-09-01 01:17:46 -03:00
ignacionelson 97596da7d0 Refuse a stored path carrying a control character 
Found reviewing the delivery work. The path is written into
X-Accel-Redirect or X-Sendfile, and a CR or LF in a header value is
header injection. PHP's header() refuses to emit one, so the real effect
is a 500 on every download, preview and thumbnail of that file rather
than a split response -- a file permanently broken by its own name.

Paths are generated here as Y/m/{uuid}.{ext}, so this should be
unreachable. The extension is not generated: it comes from the
uploader's filename, and on a migrated installation from a v1 database.
The upload routes all check the extension against an allowlist, which no
control character can match -- but upload_type_restriction can be set to
none, and the importer does not consult that policy at all.

assertRelative() was documented as the backstop for what a path may be
and only covered traversal, which is the half that cannot happen here.
Low severity, and the guard should have covered it either way.
 2026-08-31 22:57:02 -03:00
ignacionelson 2ebadf0793 Mark the downloads settings link the way the dashboard marks it 
Same amber, same underline, same warning triangle as the System widget
row. The two say the same thing about the same installation, so looking
different made the settings one read as an ordinary footnote rather than
the thing to go and read.
 2026-08-31 22:49:06 -03:00
ignacionelson 25e4f77b63 Make the whole downloads row open the explanation 
The warning triangle alone did not read as clickable. The label is now
an underlined button and the value and icon are a second one, so either
half opens the dialog and the row looks like the one thing on this card
you are meant to act on.

Two buttons rather than one wrapping the row: a dt/dd pair cannot be
nested inside a single button without losing the description-list
semantics that tie the value to its name. The value button carries an
aria-label because "PHP, button" describes nothing on its own.

Only when PHP is sending the files. On the fast path the row stays plain
text, since there is nothing to go and read.
 2026-08-31 22:44:31 -03:00
ignacionelson 90ed2d60b9 Shorten the PHP downloads explanation 
It was 2975 characters and scrolled. Same four questions answered and
nothing dropped -- what is happening, what it costs, why it is set that
way, the three ways out -- in 1696, which fits the dialog without
scrolling. The three fixes are a list rather than three headed
paragraphs, since each is one instruction.

A wall of text explaining a performance trade-off is self-defeating: the
person who most needs to read it is the one who opened the dashboard for
something else.
 2026-08-31 22:37:06 -03:00
ignacionelson d6fd5a917d Send downloads the way the web server in front of us understands 
Uploads live outside the web root, so PHP authorizes every download and
then hands the file to the web server with a header naming it. Four
routes decided that for themselves and all four hard-coded nginx's
spelling. On Apache or LiteSpeed nothing acts on the header, so the
empty body PHP sent goes to the visitor: files upload fine, thumbnails
are broken images, and downloads arrive as 0 bytes, with every other
page working. Reported as #1765 from an Apache 2.4 install, and before
that as #1266, #1215, #870 and #1271.

It is also a regression from v1, which had a download_method setting --
php, apache_xsendfile, litespeed, nginx_xaccel -- defaulting to php. v1
therefore worked on any server out of the box and v2 did not, and a v1
Apache user migrating lost every download with nothing to tell them why.

So the four sites now go through one FileDelivery, and it picks:

  auto (default)  nginx when SERVER_SOFTWARE says nginx, else php
  nginx           X-Accel-Redirect, a URL path via the internal location
  xsendfile       X-Sendfile, an absolute path (Apache mod_xsendfile,
                  LiteSpeed)
  php             BinaryFileResponse

Defaulting to auto rather than nginx is the point of the change: a
default that assumes nginx leaves an Apache install exactly as broken as
it is today until somebody reads INSTALL.md. Slow beats empty.

Auto never picks xsendfile, even where the module is loaded.
mod_xsendfile also needs XSendFilePath to allow the storage directory,
which cannot be seen from here, and choosing it on the strength of the
module being present would trade a silent failure an administrator can
diagnose from the dashboard for one nobody can.

BinaryFileResponse rather than a readfile loop because it answers Range
requests. nginx does that itself on the fast path, so hand-rolling it
would have broken seeking through a video on exactly the installations
this fallback exists for. Verified end to end: 206 with the right
Content-Range through the live stack.

Two guards. Every method checks the path cannot climb out of the storage
area -- nginx resolves `..` in the URL it is handed as happily as PHP
would -- and the two methods that hand over a filesystem path resolve it
and prove it lands inside the root. Callers pass paths from rows they
just authorized, so this is a backstop; it is here because the cost of
being wrong once is handing over any file the web server can read.

The dashboard's System panel names the method, with a warning icon and a
dialog when PHP is doing the sending: what is happening, what it costs
(one worker held for the whole of each download, so a few large
simultaneous ones can occupy every worker while the processor sits
idle), why it is set that way, and the three ways out. Written to be
accurate rather than reassuring -- nothing is broken, it does not scale
-- and the notice stays even when php was chosen deliberately, because
the trade-off is the same either way. /system/settings/downloads repeats
it, which is where somebody coming from v1 goes looking for the
dropdown.

An environment variable rather than a stored setting: it describes the
server this installation runs on, not a preference, and a value in the
database travels to a different server in a restore and is wrong there.
Read only in config/projectsend.php, so config:cache cannot blank it.

The suite pins itself to nginx. Left at auto it would detect no server
at all, fall back to php, and quietly retire the coverage of the
mechanism most installations actually use.
 2026-08-31 22:31:27 -03:00
ignacionelson 6340b71dca Report recent usage and whether the scheduler is alive 
projectsend:status could say what an installation holds and how many
accounts it has, but nothing about whether anybody was using it. Adds a
`usage` block -- downloads split staff/clients/anonymous, uploads, and
five allowlisted action counts -- plus `activity.last_client_login_at`,
`health.scheduler` and `health.failed_jobs_latest_at`.

The scheduler is the one worth having on its own. `health.queues`
catches a dead worker; nothing caught a dead scheduler, and its first
symptom is not a stalled feature but an expired file that is still
downloadable, because the job that was going to remove it stopped
running weeks ago. Nothing about the installation looks wrong while that
is true.

`failed_jobs_latest_at` exists because the count beside it cannot say
whether anything is wrong *now*, and reading it as though it could is a
category error rather than a threshold wanting tuning. The table is
swept daily, so the count spans a retention window -- one the
installation chooses, and one that can be set to keep-forever by
somebody who treats a failed job as evidence rather than debris. Two
identical installations therefore report different numbers, and on a
keep-forever one the count grows until any fixed threshold trips. A
timestamp is independent of how long rows are kept: 27 failures whose
newest is three weeks old is an installation that has been healthy for
three weeks and has not been swept yet.

`usage` is a rolling window with no lifetime totals, and that is a
correctness decision rather than a presentational one: activity_log is
never pruned, so a lifetime count over it gets slower every day of the
installation's life while a windowed one stays flat. The window is
emitted as `window_days` rather than left for the reader to assume.

The actions are an allowlist, not a `group by action`. This document
leaves the installation and Action gains cases most weeks, so an open
group-by would ship new action names outward with nobody having decided
they should go -- and some of them (account.erased, two_factor.reset)
are somebody's compliance event, not a business metric. It is also ~30x
cheaper: five keyed counts ride (action, created_at) while a group-by
starts from created_at and reads rows. The scheduler's failure message
and the queue exception text are omitted for the same reason; they are
the fields here that can carry a path or a stack trace, and a count with
a timestamp says "go and look", which is all a watcher is owed.

The two indexes ship as a pair and the migration explains at length why.
Measured at 2.1M rows: adding (action, created_at) alone fixes the
windowed counts and takes last_staff_login_at -- already running hourly
on every tenant -- from 0.63s to 7.7s, because the planner switches to
it, still needs actor_type, and does a scattered primary-key lookup per
row. With both, that query is answered from the index without reading a
row at all (0.0004s) and the whole new usage block costs ~70ms.

Also documents the keys as a contract, the way `capabilities` already
is. This one fails worse: a renamed capability key breaks a comparison
somebody is watching, a renamed usage key produces a chart that is
silently empty, and nobody gets paged for a flat line.
 2026-08-31 18:51:47 -03:00
ignacionelson fb931819e2 Translate the auth and settings screens into all sixteen locales 
#1762 put six screens through the translator and deliberately left the
new keys for a focused pass; this is that pass, plus the one older gap
the scan turned up -- the directory-account notice on the password form.

Twenty-seven keys each, written to match what the catalogue beside them
already says: de and tr formal, es, nl, pl and zh_CN informal, and each
locale's own established vocabulary rather than a fresh choice per file
(nl keeps wachtwoord, tr keeps parola, ru keeps "адрес эл. почты").

"Or, return to" and "log in" are rendered as one sentence with a space
between them, so each pair was chosen to read as a phrase in that
language rather than translated word by word -- Turkish reorders it to
"Ya da giriş sayfasına dön", Japanese to "または ログインに戻る".

Additive only: 432 insertions, nothing reordered or reformatted. The
scan now reports zero missing across all sixteen.
 2026-08-29 16:27:50 -03:00
ignacionelson 41b22d003e Merge pull request #1764 from denkfabrik-li/fix/placeholder-case-convention 
Honour Laravel's placeholder case convention in t()
 2026-08-29 16:00:17 -03:00
ignacionelson 78d5067c6b Merge pull request #1763 from denkfabrik-li/fix/zip-poll-stops-with-its-page 
Stop the zip poll when its page goes away
 2026-08-29 15:58:11 -03:00
ignacionelson b7cc5e8615 Merge pull request #1762 from denkfabrik-li/fix/auth-settings-pages-translated 
Run the auth and settings screens through the translator
 2026-08-29 14:42:04 -03:00
denkfabrik-li ed82d748ea Run the auth and settings screens through the translator 
use-translation.ts states the rule: every user-facing string in a
component must go through t(). Five screens never called it at all --
forgot-password, reset-password, confirm-password, verify-email and
settings/password had zero occurrences of useTranslation -- so a client
who had chosen Spanish reset their password in English, from the browser
tab down to the submit button. settings/profile had the hook but used it
for two strings, leaving its heading, labels and the whole
email-verification notice hardcoded around them.

The password page also carried a second, smaller mistake the miss was
hiding: its <Head> title said "Profile settings", copied from the
profile page, so the tab named the wrong screen in every language.
It says "Password settings" now, the wording its own breadcrumb and
the sibling "Notification settings" title already use.

Every string on the six screens goes through t() now. The two
module-level breadcrumb arrays moved inside their components to reach
the hook -- the shape two-factor, notifications and the other settings
pages already have. Where a key already exists in the catalogs (Email
address, Password, Confirm password, New password, Log out and friends,
shared with the login screen) the existing translations light up
immediately; the keys new to the catalogs fall back to their English
text, exactly what those lines rendered before, until the locales pick
them up.

TranslationUsageTest is the guard, a source scan like
DateFormattingUsageTest and for the same reason: no JavaScript test
runner gates this class of miss. It fails on any page under pages/auth
or pages/settings that never uses the hook -- those screens always carry
copy of their own, so a page there without it is a page somebody forgot
-- and on any literal <Head title="..."> anywhere, which is both a
user-facing string and where the copy-paste title above lived. Both
scans go red on the tree without this change: five pages and six
literal titles.
 2026-08-29 08:58:00 +02:00
denkfabrik-li fe3b7b7018 Honour Laravel's placeholder case convention in t() 
The frontend translator replaced placeholders by exact match only:
`:${name}`, nothing else. But the catalogs it consumes are Laravel JSON
catalogs, and Laravel's convention has always been three forms — :name
receives the value as-is, :Name capitalized, :NAME upper-cased. The
backend translator honours all three; fifteen values in lang/nl.json
and one in lang/tr.json already rely on it. Dutch writes "Add :name" as
":Name toevoegen" because the noun opens the phrase there and gets the
capital; Turkish does the same with "Go to page :page" as ":Page
sayfasına git". Through this hook, those sixteen values rendered the
literal ":Name" and ":Page" instead of the replacement — the value was
right for the language and wrong only for the half of the app that
reads it with an exact-match replace.

t() builds the three variants per replacement now, longest placeholder
first — strtr's implicit rule made explicit, so with :name and :names
both in play, :name cannot eat the front half of :names. Ties keep
insertion order, which resolves a fully-colliding key to the as-is
value, the same answer the backend's assignment order produces.

No test accompanies this: there is no JavaScript test runner in the
project, and the PHP suite exercises the backend translator, which was
never wrong. Counter-checked by running both implementations over the
affected catalog values in node — the old replace leaves ":Name
toevoegen" and ":Page sayfasına git" literal, the new one renders
"Bestand toevoegen" and "2 sayfasına git" — plus the existing in-repo
call shapes (":used of :limit", ":name — files"), which come out
byte-identical to before.
 2026-08-29 08:57:49 +02:00
denkfabrik-li 6783fa0b81 Stop the zip poll when its page goes away 
useZipDownload sets an interval that polls zip-downloads/{id} every two
seconds until the build reports ready or failed. The only paths that
ever cleared it were those two answers and close() — there was no
unmount cleanup at all, no useEffect in the file. But the pages that
hold the hook are Inertia pages: navigating away unmounts them without
close(), and the interval keeps hitting the endpoint every two seconds
for as long as the tab lives, polling for a download nobody can receive
any more. A zip stuck in pending — the exact case the polling exists
for — polls forever.

Three holes, one leak:

- No cleanup on unmount. A useEffect returning stopPolling closes the
  main path.
- An unmount while the store POST is still in flight: its then() runs
  after the cleanup already did, and would set a fresh interval on the
  dead component. The unmounted flag makes that then() a no-op.
- A second start() while a poll is running overwrote pollRef and
  orphaned the first interval the same way. start() stops the previous
  poll first now.

No test accompanies this: there is no JavaScript test runner in the
project, and the PHP suite never mounts a component. Verified with
tsc, eslint and prettier, and by reading the two consumers —
files/index.tsx and use-portal-files.ts — both of which only ever
clear the interval through the dialog's onClose today.
 2026-08-29 08:57:49 +02:00
ignacionelson 4556ccf691 Merge pull request #1761 from denkfabrik-li/fix/self-hosted-font 
Serve the interface font from the installation, not from a font CDN
 2026-08-29 02:34:53 -03:00
ignacionelson 85572eb45e Write up the image's production defaults for operators 
#1760 changes how an existing installation behaves on the next pull, and
the part worth saying out loud is the one nobody could see: "reject
known-breached passwords" was reporting itself as on while doing nothing.

Filed under Security with who was actually affected -- not anyone
following the documentation -- and under Upgrade notes with the one thing
that stops working: APP_ENV and APP_DEBUG edited inside storage/.env.
 2026-08-29 02:32:40 -03:00
ignacionelson 227a08dfce Merge pull request #1760 from denkfabrik-li/fix/image-defaults-to-production 
Have the production image default to production
 2026-08-29 02:32:21 -03:00
ignacionelson 43e9985b2b Write up the quickstart's loopback binding for operators 
#1759 changes a file people copy verbatim, so the change has to reach
them somewhere other than a diff: anyone who copied the old example and
reaches the app on <server-ip>:8080 will find it stops answering.

Filed under Security with the reason it was a finding at all -- a
published Docker port is not covered by a host firewall, so the port was
often open without anyone intending it -- and under Upgrade notes with
what to do when the proxy lives on another machine.
 2026-08-29 02:30:15 -03:00
ignacionelson f931c6a492 Merge pull request #1759 from denkfabrik-li/fix/quickstart-binds-to-loopback 
Publish the quickstart on loopback, since it trusts any proxy
 2026-08-29 02:29:52 -03:00
ignacionelson 1a3260a397 Merge pull request #1758 from denkfabrik-li/fix/confirm-password-asks-the-directory 
Let the confirm-password screen ask where the password lives
 2026-08-29 02:05:49 -03:00
ignacionelson 07e7132747 Merge pull request #1757 from denkfabrik-li/fix/dont-flash-stored-secrets 
Stop a rejected settings form flashing the credential it carried
 2026-08-29 01:21:13 -03:00
ignacionelson f4fd194991 Merge pull request #1756 from denkfabrik-li/fix/provider-link-password-confirm 
Make linking a provider re-prove the password
 2026-08-29 01:16:16 -03:00
ignacionelson ea45943f40 Merge pull request #1755 from denkfabrik-li/fix/credential-checks-rate-limited 
Give every password check in front of an account its own bucket
 2026-08-29 01:10:53 -03:00
ignacionelson ce96313710 Merge pull request #1754 from denkfabrik-li/fix/api-group-members-response-scope 
Narrow the membership an API member write hands back
 2026-08-29 01:09:46 -03:00
ignacionelson 77dd5ff90b Merge pull request #1753 from denkfabrik-li/fix/account-conversion-list-scope 
Narrow the conversion list to the clients its own refusal allows
 2026-08-29 01:07:22 -03:00
ignacionelson 8984aba7d8 Merge pull request #1752 from denkfabrik-li/fix/preference-writes-bounded 
Bound the two preference endpoints by their own registries
 2026-08-28 23:41:46 -03:00
ignacionelson 188848b549 Merge pull request #1751 from denkfabrik-li/fix/credentials-in-boot-cache 
Keep the mail and storage credentials out of the boot-config cache
 2026-08-28 22:56:37 -03:00
denkfabrik-li 7264c44fd7 Serve the interface font from the installation, not from a font CDN 
app.blade.php is the root template for all three interfaces, and it opened
with two lines pointing at a third party:

    <link rel="preconnect" href="https://fonts.bunny.net">
    <link href="https://fonts.bunny.net/css?family=instrument-sans:400,500,600" rel="stylesheet" />

Every visitor to /login, /register, /forgot-password, /s/{token} and every
public listing page therefore made a request to a host the operator did
not choose and could not switch off, before they had done anything at all
-- handing it their IP address, their user agent, and through Origin the
hostname of the installation they were visiting. On the signed-out pages
that is a visitor who has agreed to nothing, and an operator who often has
told their own users that this server is where their files live.

There was no self-hosted copy in the repository, no setting, no mention in
INSTALL.md, DOCKER.md or SECURITY.md, and no SRI on the tag.

The font now ships with the application, through @fontsource/instrument-sans
-- the same font, the same three weights the URL asked for, from a
versioned dependency rather than binaries pasted into the repository.
Vite fingerprints and emits them like any other asset.

Cost, measured on this build: twelve files, 192 KB on disk. A browser
fetches only woff2 and only the subsets it needs, which is 73 KB for all
six woff2 files together and typically 41 KB (latin, three weights) for a
page in English. Against that, every page load loses a DNS lookup, a TLS
handshake and a round trip to another origin, so signed-out pages get
faster rather than slower.

This is a privacy change rather than a vulnerability fix, and worth saying
plainly: the share token does not leak this way. Referrer-Policy:
strict-origin-when-cross-origin is set in both nginx configs and in the
INSTALL.md snippet, so the path never travelled in the Referer. What
travelled was the visit itself.

Not changed: public/.htaccess still sets no security headers at all, so an
Apache installation has no Referrer-Policy. That is a real gap and a
separate change.

Verified: `npm run build` succeeds and emits the faces; no reference to
the CDN survives anywhere in public/build; `tsc --noEmit` and prettier are
clean. No test asserts on the font, before or after.
 2026-08-29 00:50:02 +02:00
denkfabrik-li 3e24ccd42f Let the confirm-password screen ask where the password lives 
ConfirmablePasswordController checked the local hash and nothing else:

    Auth::guard('web')->validate(['email' => ..., 'password' => ...])

An account provisioned from a directory has no local password. It holds a
Str::password(64) generated at provisioning time that nobody has ever
seen, and the application knows this -- LdapAuthenticator::isDirectoryAccount()
is the question, and the sign-in form asks it before deciding what to
check. This screen did not, so it refused those accounts the only password
they have.

That is not a cosmetic refusal. `password.confirm` stands in front of
enrolling in two-factor, so a directory-provisioned client could not enrol
at all. Set TwoFactorEnforcement to `clients` or `all` and EnforceTwoFactor
redirects every request they make to two-factor.show -- a screen whose
"enable" button leads to a door they cannot open. PR #1708 fixed the
routing half of that ("Let an enforced user reach the far side of the
confirm-password screen"); this is the credential half.

The rule now lives in one place. PasswordVerification is the sibling of
SignIn on the other side of the line SignIn draws -- SignIn is everything
after a credential checks out, this is the one question asked before it --
and it exists for the reason SignIn gives for existing: "the way they get
broken is by being written twice". LoginRequest keeps its ordering, its
provisioning and its rate limiting, and delegates the check itself.

Behaviour preserved exactly on the sign-in path: local hash first so an
account that answers locally generates no directory traffic, directory
only for accounts whose credentials live there, the stale-hash re-hash on
the local branch only, and the ldap_dn stamp on the directory branch. All
23 existing LDAP sign-in tests pass unchanged.

One thing this closes on the way past. Because the old check went straight
to the local hash, a directory account's placeholder *would* have confirmed
if anybody ever learned it -- a door the sign-in form does not have, since
it skips the local branch for those accounts. It now behaves the same on
both screens; there is a test.

**What this does not fix, and should be read as a limitation.** Accounts
provisioned by a social provider are in the same position -- a random local
password nobody holds -- and they are not directory accounts, so this
changes nothing for them. Their route to a local password is the password
reset, which #1748 made work end to end by moving auth_source to Local when
the reset completes. A social account that has never done that still cannot
confirm a password, and so still cannot enrol in two-factor.

Tests: three fail against the unfixed pair, including the placeholder case
above. Two more pin what must not change -- a wrong directory password is
still refused, and a local account with LDAP switched on still confirms
against its own hash.
 2026-08-29 00:10:59 +02:00
denkfabrik-li 74077993de Have the production image default to production 
The entrypoint seeds the .env on the storage volume when there is none:

    if [ ! -f storage/.env ]; then
        cp .env.example storage/.env

.env.example is the development template. It carries APP_ENV=local and
APP_DEBUG=true, and the Dockerfile set no defaults of its own -- its only
ENV was PROJECTSEND_IMAGE=1.

Real environment variables win over that file, so compose.example.yaml
(APP_ENV: production, APP_DEBUG: "false") was never affected, and neither
was anybody following the documentation. Everybody else was: `docker run`
with nothing but a database address, the Portainer / unRAID / TrueNAS
templates people actually use, a Kubernetes manifest naming only
DB/Redis/APP_URL. All of them booted a debug build and nothing said so.

Two things follow, and neither is visible from inside the application:

1. **Every 500 hands its stack trace to whoever caused it**, signed in or
   not -- Laravel's exception page, with the file, the line and the
   surrounding source. docker/production/php.ini sets display_errors=Off
   and that does not help, because Laravel renders the page itself rather
   than letting PHP print it.

2. **"Reject known-breached passwords" never ran.** PasswordPolicy::rule()
   appends ->uncompromised() only when app()->isProduction(). On
   APP_ENV=local an administrator could switch the setting on, watch
   descriptor() advertise it on every password form and the security
   settings screen report it as active, and have it do nothing.

The image now states its own environment.

Set in the Dockerfile rather than in the seeded .env on purpose: the copy
only happens when no .env exists, so seeding would fix a fresh install and
leave every installation already running on a stale one exactly as it is.
As an ENV it takes effect on the next pull.

What it does not outrank: Laravel builds its env repository immutable
(Illuminate\Support\Env), so a real environment variable beats the .env
file. `docker run -e`, compose `environment:` and Kubernetes `env:` all
set real environment variables, so an operator who asks for something
explicitly still gets it -- verified against this image, where a .env
saying local/true is overridden to production/false by the variables.

The trade-off, stated because it is a behaviour change: editing APP_ENV or
APP_DEBUG inside storage/.env no longer has any effect, since these are
real environment variables and that file is not. Turning debug on
deliberately is `-e APP_DEBUG=true`, which still works. That is written
into the Dockerfile comment so the next person finds it there.

Not changed: PasswordPolicy's isProduction() test itself. Tying an
administrator's setting to the environment rather than to the setting is
arguably wrong on its own, but it is a separate question with its own
blast radius, and this change makes the shipped image behave the way that
code already assumes.

No test: the environment an image ships is not observable from the suite.
`docker build --check` reports no warnings on the edited file.
 2026-08-29 00:07:12 +02:00
denkfabrik-li da7eb6f67d Publish the quickstart on loopback, since it trusts any proxy 
compose.example.yaml does two things that are each fine alone and unsafe
together:

    ports:
      - "8080:80"            # Docker binds 0.0.0.0 unless told otherwise
    environment:
      TRUSTED_PROXIES: "*"   # believe the X-Forwarded-For of whoever connects

Behind a proxy that appends the header, "*" is correct and harmless --
Symfony strips the peer and takes the real client the proxy appended. The
example never gets there. It publishes the container on every interface,
so a visitor can reach port 8080 themselves, and then *they* are the peer
the application has been told to trust. `X-Forwarded-For: 203.0.113.9`
makes request()->ip() return exactly that.

What that costs, all of it on the signed-out surface:

  - the login lockout, keyed on `email|ip` in LoginRequest::throttleKey()
  - throttle:6,1 on register, password-email, password-reset, two-factor
  - throttle:30,1 on share-link, public-browse, public-comment
  - the download log, the activity log, and the `ip_address` recorded on
    guest comments -- which FileComments::post calls "the one handle that
    makes spam actionable"

Rotate the header and every one of them counts a different attacker.

The project's own test states the primitive: TrustedProxiesTest sets
trustedproxy.proxies = '*', sends X-Forwarded-For from a *direct* client,
and asserts the address is taken.

The documentation has always qualified "*" correctly -- .env.example says
it is "only safe when nothing but the proxy can reach the app", and
dockerhub-overview.md repeats it. The example file is what did not meet
its own precondition, and it is the file the Docker Hub description tells
a first-time reader to copy.

Publishing on 127.0.0.1 restores the precondition: a proxy on the host, or
in this compose file, still reaches it; nothing off the machine does. This
repository's own compose.yaml already publishes Adminer that way, for the
same reason.

The two settings are now documented as a pair in all three places that
carry them, including what to do when the proxy is on another host: bind
to the interface it arrives from and name that address in TRUSTED_PROXIES
instead of "*".

DOCKER.md's health-check command changes with it -- it told the reader to
curl <host-ip>:8080 from the same machine, which the new binding does not
answer. It now says 127.0.0.1:8080.

No test: this is packaging and prose. `docker compose config` parses the
edited file.
 2026-08-29 00:05:03 +02:00
denkfabrik-li 35d68a792b Stop a rejected settings form flashing the credential it carried 
When validation fails, Laravel flashes the request's input into the
session so the form can be repopulated. Its exclusion list is
current_password, password and password_confirmation -- written for the
login and password screens, and covering none of the credentials the
system settings screens take. `dontFlash` did not appear anywhere in this
repository.

So every one of these went into the session in clear the moment its form
was rejected:

    secret          ExternalStorageSettingsController   (S3 secret access key)
    key_file        ExternalStorageSettingsController   (GCS service account JSON)
    bind_password   LdapSettingsController
    client_secret   SocialLoginSettingsController, EmailSettingsController
    secret_key      CaptchaSettingsController

Each is stored with an `encrypted` cast, and config/session.php puts
sessions in the database with `encrypt => false` -- so the rejected save
wrote in clear into the same database the cast exists to protect.

The sharpest one is key_file. serviceAccountKeyRule() exists to catch a
paste that lost its last line, which makes "the request carrying a
service account private key" and "the request that fails validation" the
same request more often than not.

dontFlash() merges rather than replaces, so the framework's three stay.

The cost is that these five come back blank after a failed save. That is
already what they do after a successful one -- every screen here treats
them as write-only, and a blank means "keep what is stored" -- so the
behaviour is now the same either way instead of only on success.

Tests: one per field, each submitting a form that fails validation while
carrying a secret, then reading the old input back the way the form
would. All five fail against the unmodified bootstrap/app.php. A sixth
pins that the framework's own three are still excluded, and each
assertion checks a neighbouring non-secret field still comes back, so
this cannot pass by flashing nothing at all.

Note for the record: this is testable in the existing harness after all.
phpunit.xml sets SESSION_DRIVER=array, but old input is written to the
session whatever the driver backs it, so getOldInput() sees exactly what
a database session would have stored.
 2026-08-29 00:02:21 +02:00
denkfabrik-li bde86c10e4 Make linking a provider re-prove the password 
Connecting a provider needed nothing but the session. Anyone holding one
could POST /settings/connected-accounts/google, follow the returned
Inertia::location(), sign in at the provider as *themselves*, and
completeLink() would bind their identity to the victim's account.

SocialAccount says what that row is:

    This row *is* the authorization to sign in as that account.

So it is not a preference -- it is a credential, and one that outlives
every way the victim has of ending the session that created it. It
survives a password change, it survives Auth::logoutOtherDevices(), it
survives invalidating every session. Where a stolen session gives an
attacker access until it is noticed, this gives them an account.

routes/settings.php already makes exactly this argument, twenty lines
down, for the two-factor block and the API token routes:

    a token outlives the session that minted it, so a stolen session must
    not be enough to mint one

The link has that property too, and was the one thing on this screen
without the gate. Now it has it.

The gate goes on `connect`, not on the callback: starting the flow is what
writes the intent the callback completes, and the callback deliberately
sits outside every group so a provider sign-in works without a session.

Not changed, deliberately: `connected-accounts.destroy`. Disconnecting
removes a way in rather than adding one, and destroy() already refuses to
remove the last one ("This is the only way you can sign in. Set a password
first"). Putting it behind password.confirm would fall hardest on the
accounts a provider provisioned -- they hold a Str::password(64) nobody
has ever seen -- and leave them unable to disconnect anything at all.
There is a test pinning that it stays reachable.

Also not changed: the account owner still is not told. SocialLoginController
writes an activity log entry, and that sits behind `staff` +
can:view_actions_log, so a client never sees it. Notifying them is a real
gap and a separate change; this one closes the door rather than adding a
bell to it.

Tests: two that fail against the ungated route -- the redirect, and the
whole attack end to end with a stranger identity never binding. The
existing connect() helper now confirms the password, the way
enableTwoFactor() already did, so the rest of the file keeps exercising
the real gate rather than asserting around it.
 2026-08-28 23:59:11 +02:00
denkfabrik-li c72adadc44 Give every password check in front of an account its own bucket 
POST /confirm-password verified the account's password and counted
nothing. Forty wrong guesses, forty identical refusals, no lockout, no
Retry-After, no log line.

routes/auth.php opens by requiring the opposite:

  **Every `throttle:` below names its own bucket, and must.**

and every other route in the file has one. POST login is the deliberate
exception, and the file says why -- LoginRequest limits it per email *and*
IP, which is a stronger boundary than a per-IP count. confirm-password had
neither of those things.

It is the wrong door to leave unlatched. Re-proving the password is what
stands between a stolen session and disabling two-factor, regenerating
recovery codes, or minting an API token -- credentials that outlive the
session, which is the reason routes/settings.php gives for putting those
routes behind it. An attacker who already holds the session can sit on
this endpoint until the password falls out of it, and then has the
password for everything else too.

Two more with the same shape, in routes/settings.php:

  - PUT /settings/password -- update() validates `current_password`.
  - DELETE /settings/profile -- destroy() validates `current_password`.

Both were equally uncounted, and both answer the same question in the same
way, so an attacker refused at one door simply used the next. Fixing one
of three would have been cosmetic.

All three get named buckets at 6/1, matching the credential-facing routes
already in auth.php. Named rather than bare: a bare `throttle:` keys on
sha1(domain|ip) or sha1(user_id) with no route in it, which is how six
share links once locked a visitor out of the two-factor challenge.

Not changed: POST /logout has no bucket either and does not need one -- it
checks no credential and reveals nothing by being repeated. PATCH
/settings/profile likewise.

Tests: three that fail against the unthrottled routes, and two that pin
what the buckets must not do -- exhausting one must not spend another's,
and one account's guesses must not lock a different account out.
 2026-08-28 23:55:58 +02:00
denkfabrik-li 1ed29ec072 Bound the two preference endpoints by their own registries 
Both preference writers validated their array as ['required', 'array']
and looped updateOrCreate over it:

    'widgets' => ['required', 'array'],
    'widgets.*.widget_key' => ['required', 'string', Rule::in(WIDGET_KEYS)],

Rule::in answers "is this a key I know", once per element. It says
nothing about how many elements there are, and nothing about whether they
repeat -- so a request could name the same valid key any number of times
and buy a SELECT and an UPDATE for each one.

Measured on this base, sent as JSON (a form-encoded array that size is
truncated by max_input_vars long before it reaches the controller):

    widgets        10 entries    37 queries   1 row
                  500 entries  1044 queries   1 row
                 3000 entries  7051 queries   1 row

    notifications   10 entries    23 queries   1 row
                 2000 entries  2025 queries   1 row

One row, every time. The work is not even data growth -- 3000 entries
write the same single row 3000 times, because updateOrCreate matches on
(user_id, widget_key) and every element after the first is an update of
what the one before it just wrote.

Neither route is behind a throttle: bootstrap/app.php applies
throttleApi() to the API group only, /dashboard/widgets is behind `auth`
alone and /settings/notifications is deliberately outside the `staff`
group, since every account manages its own. So the weakest account on the
installation -- a client with no permission at all -- can reach both, and
the only ceiling is post_max_size.

Both are bounded by the list they already validate against, not by a
number:

  - widgets by count(self::WIDGET_KEYS), the same constant Rule::in reads.
  - preferences by count($this->emailableKeys()), because
    NotificationTypeRegistry is deliberately open -- "never a closed enum,
    since core must not need to know a package's notification type keys at
    compile time" -- so a literal would be wrong the day a module
    registers one.

`distinct` on the key does the other half: a layout has at most one entry
per widget, which is what the screen sends and what the loop assumes.

After: 3000 entries cost 30 queries and write nothing, refused with a 422
instead of half-applied.

Two findings, one cause, one change -- they are the same three words in
two modules, and splitting them would leave the rule stated once and
broken once. Tests live with each controller: two refusals each, both
failing against the unfixed controllers, plus one for the largest
legitimate submission -- a full nine-widget layout, and every emailable
type at once -- so the bound can never be tighter than the screen.
 2026-08-28 23:53:12 +02:00
denkfabrik-li 9af0d643b1 Keep the mail and storage credentials out of the boot-config cache 
MailConfigApplier and ExternalStorageConfigApplier read their settings
through the `encrypted` casts -- decrypted -- and wrote the result into
the cache store with rememberForever(). The SMTP password, the S3 secret
access key and the whole GCS service account key file, private key
included, went in as plain text under a key that never expires.

The cache store encrypts nothing. On the store INSTALL.md documents for a
manual install (CACHE_STORE=database) and config/cache.php defaults to,
that is the `cache` table of the same database whose dump the `encrypted`
cast exists to survive. On redis it is the redis dump.

The rule already exists, two files away. MailOAuthConnection states it:

  Transports read this row fresh at send time -- tokens must never travel
  through the boot-config cache (see MailConfigApplier, which caches only
  readiness and the account address).

MailConfigApplier's own cache-key comment says the same thing about the
same array: what is deliberately NOT in the cached shape is tokens,
because neither readiness nor an address is a credential. The SMTP
password was in it anyway. SocialSettings::available() names both classes
outright as making the mistake.

So the credentials are read the way the tokens already are: from the row,
at the point that uses them. The cached array keeps everything that is
not a credential, and each applier reads its secret inside the branch
that configures a transport -- an installation on OAuth, on cloud, or one
that has never opened the Email or Storage screen reads nothing extra.

BootSettingsCache grows a second entry point rather than the callers
restating its rule. The cached read already survives a database with no
tables, because booting must not require this application's own database;
an uncached credential read on the same path needs exactly that guarantee
and nothing else, since resolve() can hand back a warm "configured" from
a database that has since stopped answering.

Both cache keys are bumped, as their comments require on a shape change.

Tests: five for the absence, two of them against the database cache store
read as the raw rows an operator would find in a dump, since phpunit.xml
runs the suite on the array store and the cache path was structurally
invisible -- which is why GoogleCloudStorageTest could assert that the private
key is not in the column while it sat in the cache. All five were run
against the unfixed appliers and fail there. The three "still configures
what it no longer caches" tests deliberately pass either way: they pin the
behaviour the fix must not break.
 2026-08-28 23:46:19 +02:00
denkfabrik-li 19ee9d9833 Narrow the membership an API member write hands back 
Adding or removing a group member answered with the group, and loaded the
relation whole:

    return new GroupResource($group->loadCount('members')->load('members'));

GroupResource gives each member an id, a name and an email. So a
client-scoped staff member who added one of their own clients to a group
was handed, in the same response, the name and address of every other
client in it -- people they may not read anywhere else in the application,
and whom the group edit screen refuses to name for exactly that reason.
syncWithoutDetaching() makes the call idempotent, so the same request
returns the same list as often as it is sent.

The boundary is already written down. GroupResource's docblock:

  both narrow the list to the clients the viewer may act on, and the
  controller loading this relation is where that narrowing is applied

and Api\GroupsController::show() does it for the read of the same group,
noting that "it hands back the membership with addresses". Changing the
membership is not a reason to be told more than reading it is, so both
halves now narrow by the same query, through one private helper rather
than a third copy of it.

members_count is deliberately left whole, matching show(): a size is not
an identity, and it is the number the group listing already reports.

Nothing about who may perform the write changes -- StaffLibraryScope
::allowsGroupMembership() already decided that, and still does. This is
only what the answer is allowed to say.

Tests: added beside the existing "the API twin narrows the membership it
hands back", which covered the read half only. Both write tests fail
against the unfixed controller; the third pins that an unscoped token
still gets every member.
 2026-08-28 23:46:18 +02:00
denkfabrik-li cad112522d Narrow the conversion list to the clients its own refusal allows 
/users/convert lists the accounts a conversion can be started from. For
the promotion direction those are clients, and the query asked only for
the type:

    User::query()->where('type', UserType::Client)

The write beside it does not. AccountConversion::guardToStaff() ends with

    abort_unless($this->library->canAssignClient($actor, $target), 404);

and says why: a promotion is the most far-reaching thing that can be done
to a client, so reaching one outside the actor's roster "through this door
and no other is not a rule, it is a gap".

The gap was on the way in. A client-scoped staff member holding
manage_users and edit_users was refused the promotion with a 404 -- the
refusal that is careful not to distinguish a stranger from an account that
is not there -- and then shown that same person's name, email, role,
status and consequence counts in the list the refusal came from,
searchable by name or address and paginated to the end.

StaffLibraryScope::clients() is canAssignClient()'s listing half, written
for this: "so a screen narrows by the same rule its buttons are guarded
with rather than restating it -- which is how ClientsController came to
list every client on the installation, name and email, to a viewer who
could reach nothing of theirs." The picker twenty lines below already went
through the same boundary via assignableClientIds().

Only the client direction is narrowed. The staff direction is left exactly
as it was: whoever may demote a staff member may see the staff roster, and
what limits a demotion is guardTarget() on the write, not the listing.

Tests: the listing half added to AccountConversionScopeTest, which until
now covered only the refusals. Two of the five fail against the unfixed
controller -- the stranger's address in the list, and reaching it by exact
search. The other three pin what must not change: the actor still sees
their own client, unscoped staff still see everybody, and the demotion
list still lists staff.
 2026-08-28 23:38:48 +02:00
ignacionelson 81bb136e9e Merge pull request #1750 from denkfabrik-li/fix/mail-oauth-alarm-fires-once 
RefreshMailOAuthTokensCommand is the daily refresh and, by its own docblock, the health check that goes with it: a delegated grant can die silently, and for a portal whose password-reset mails ride on this connection that must surface as a warning rather than as a support ticket weeks later. It decided whether to warn from last_error -- but last_error has a second writer. OAuthCodeFlowBroker::refresh() records a dead grant and notifies nobody, and freshAccessToken() reaches it from every send. So on an installation that is actually sending mail the send got there first, the command read the column as "already told them", and the warning never went out. last_error is cleared only by a successful refresh, which a dead grant never has, so it never went out later either. The alarm worked on installations that were not using the mailbox and failed on the ones that were.

The anti-nag rule is not the problem and does not change: one notification per broken state is still all anybody gets. The problem is that one column was answering two questions, which the table's own comment describes -- "what the settings page's warning and the admin notification read". The warning wants "is this connection broken", and any writer may answer it, which is why the settings page turning red on a failed send is correct and stays. The notification wants "have the admins been told", and only the notifier can answer that.

broken_notified_at is stamped when the command notifies, and the command asks that instead. It is cleared wherever last_error is cleared -- a successful refresh, a disconnect, a changed client id -- and those three sites now call clearFailure() rather than nulling two columns each, because a connection left healthy but still marked "already told them" would go quiet the next time it died, and a fourth caller is exactly how the first one happened. The send path still records the failure and still notifies nobody: a transport is not a place to decide who gets alarmed.

Verified before merging: 27 passed on the merged tree, 2 failed / 25 passed with app/ reset and the migration and tests kept. The recovery test is green either way by design. This touches the same command and broker as #1739 and the follow-up to it, so the merged result was read rather than trusted: the refresh reporting sits in the try and the notify guard in the catch, they do not interact, and refreshSerially() re-reads the row before refreshing so the broken_notified_at the catch reads is the stored one -- while a stand-aside throws nothing and never reaches the catch at all.

Note for the next release's upgrade notes: this adds a migration, so "nothing to do beyond dropping in the files" no longer holds.

Reported and fixed by @denkfabrik-li.
 2026-08-28 18:04:37 -03:00
ignacionelson a2bc3fa163 Merge pull request #1749 from denkfabrik-li/fix/deleted-comment-author-type 
file_comments.author_id is cascadeOnDelete and the cascade never fires, because a user is soft-deleted. The row behind a deleted commenter is still there and the column still points at it -- the relation just would not hand it over, and every caller then had to invent a meaning for the absence. They invented different ones: the author type became "guest" on the moderation screen and on the file's own thread, and "client" in the API, each printed beside a name that stayed correct, so one row said "Dana Staff" and "guest" at the same time. The author filter and the name search stopped matching the comment altogether, which is the worse half: a moderator filtering for staff comments did not see a staff comment sitting in front of them, and nothing about that looks like a missing row.

This is the author half of #1717, and DeletedClientThreadTest's docblock already described both columns. FileComment::authorName() was the one place that reached past the relation by hand, which is why the names were right while everything beside them was wrong.

The relation is fixed rather than the five call sites: author() reads a deleted account, and the API resource, the author filter and the name search then need no change at all, because they were already asking the right question of a relation that would not answer it. The two authorType() copies now ask author_id, which after the relation fix answers the same either way -- written that way because "no author row means guest" is exactly the reading that produced the bug.

Verified before merging: tests/Feature/Comments at 186 passed on the trial-merge, 5 failed / 1 passed with app/ reset. The survivor is the guest guard, green either way, which is what says this did not simply relabel everything as staff. scramble:export reproduces the spec byte for byte.

No visibility widens, and that was checked rather than taken on trust: every decision point in VisibleCommentScope and FileCommentPolicy compares author_id directly, five sites, none through the relation. No new field is exposed either -- the API resource reads only id, name and type from the author, and name already went through authorName()'s withTrashed lookup. Deleting an account still takes its comments with it when the grace period ends, since author_id is cascadeOnDelete.

Reported and fixed by @denkfabrik-li.
 2026-08-28 18:03:03 -03:00
ignacionelson ef6f8fea56 Merge pull request #1748 from denkfabrik-li/fix/password-reset-credential-source 
Two accounts reach the same reset with opposite needs, and it answered both by writing a hash and hoping.

A provider account is asked for something it cannot do. The Connected accounts screen refuses to release an account's last provider -- "Set a password first, then disconnect Google" -- and nothing set auth_source back to Local, so the screen went on asking for what had just been done, with no way out from inside the application. AuthSource already states the rule that closes it, for this case by name: a social account may later set a real password, and social only means the account came into existence without anybody choosing one. A reset by emailed token is where somebody chooses one, and the prop the screen reads is literally auth_source === Local under the name has_local_password.

A directory account is told something untrue. isDirectoryAccount() means the local hash is not consulted at all, so the same reset wrote a password that could never sign anybody in and reported success -- including when the directory it points at is gone, which is exactly the situation that sends somebody to a reset.

The reset now asks where the account's credentials live. social becomes Local, because the new password is the credential now. A directory account is refused, with the reason, and nothing about it moves -- writing Local there would not record something that had happened, it would take the account off its directory as a side effect of a password reset, which is an administrator's decision and already lives in AccountConversion with the password requirement and activity entry that belong to it. Everything else is byte for byte as before.

Verified before merging: 20 passed on the trial-merge, 2 failed / 18 passed with app/ reset, and the wider suites green -- tests/Feature/Auth 96 passed, tests/Feature/Identity 302 passed. Four properties were checked in the framework rather than argued. PasswordBroker::reset() calls validateReset() before the callback, so the refusal only reaches somebody holding a token emailed to that address and nothing is enumerable. It deletes the token after the callback, so a throw leaves the link usable. Every use of AuthSource::Local is in ConnectedAccountsController -- the has_local_password prop and the last-provider guard -- so the social-to-Local flip grants exactly the ability the screen instructs the user to obtain and nothing else, and no new login capability at all, since password login already worked for social accounts. And the check is isDirectoryAccount() rather than an auth_source comparison because LDAP is client-only, so staff are not refused; the test for that is green either way.

One new string is English only for now: "This account signs in through your directory, so its password is not set here."

Reported and fixed by @denkfabrik-li.
 2026-08-28 18:01:47 -03:00
ignacionelson 927c8fc991 Translate the bulk edit's second skip reason 
#1747 split the bulk edit's skip message in two, because "you don't have permission to edit them" was being said to somebody about files they own. The new sentence arrived English only, so every non-English installation would have read the correct reason in the wrong language.

Translated from its near-twin rather than from scratch: the two messages differ in one clause, so each locale keeps the first sentence it already had, its own register -- de and tr formal, es, nl, pl and zh_CN informal -- and only the reason changes. That way the pair reads as one voice on the same screen, which is where a staff member meets both.

Added immediately after the sibling key in each file, which is also its sorted position, so the diff is one line per locale and nothing else moved.
 2026-08-28 17:59:29 -03:00
ignacionelson 144f5fc578 Merge pull request #1747 from denkfabrik-li/fix/bulk-edit-skip-reason 
Two different things stop a selected file being changed in a bulk edit, and bulkUpdate() reported both as the first one. Files dropped by the Gate::allows('update') filter are ones this staff member may not edit at all. A file that survives the filter and still changes nothing is a different case: it was editable, and every field they asked to change is one their role does not let them set -- expiry, download limit and categories each sit behind their own permission here, exactly as they do in the single-file editor. So a staff member with edit_files but without set_file_expiration_date, editing three files they own, was told "0 of 3 selected files were updated. The rest were skipped because you don't have permission to edit them." They own all three, and editing is precisely what they may do: the sentence was both wrong and unactionable, since nothing in it points at the permission that actually stopped the edit.

The two cases get their own sentences now. Every skip being a file they may not edit keeps the existing string, unchanged, so its sixteen translations stay in use. Anything else gets a new one, "because you don't have permission to make those changes", which is also true when both reasons are in play, so a mixed selection is described correctly rather than approximately. Which files get changed is untouched, as is the silent-skip convention and the 422 when nothing at all is authorised.

Verified before merging: 14 passed on the trial-merge, 2 failed / 12 passed with app/ reset -- the field-permission case and the mixture. The pure edit-permission case is green either way, which is what says the existing message was not disturbed. FilesController overlaps #1728, already merged, and its expiryDateFor work is intact in the merged tree.

The new string arrived English-only; the sixteen catalogs are filled in the commit that follows.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:58:14 -03:00
ignacionelson 383c3b2ff5 Merge pull request #1746 from denkfabrik-li/fix/expired-file-staff-access-comment 
File::isExpired() documented the rule the whole application is supposed to follow: once past, the file is hidden from clients and the public site but staff keep full access. The second half is not true of a client-scoped staff member. StaffLibraryScope::buildFiles() builds their library as own uploads plus what each assigned client may see, and that second half runs through File::scopeVisibleToClient, which ends in notExpired() -- a client-side rule. So an expired file they held only through a client leaves their library and answers 403 on download, while their own expired upload stays and an unscoped administrator is unaffected. Api\FilesController stated it the same way, "Only the client branch of the visibility rules drops them", which reads as though a staff caller is unaffected when a client-scoped one is reached through that very branch.

This does not change that behaviour. c8078f65 weighed widening it and decided against, because scopeVisibleToClient is the single source of truth for client file access and the highest-stakes function to go changing for a dashboard widget, and relabelled the widget instead. That decision lived in a commit message and one widget's label; nothing in the code said it, and the docblock nearest the rule went on promising the opposite -- which is how the next person re-derives "staff keep full access" and widens the scope to match.

Documentation and characterisation only. isExpired() now states the boundary and why it is where it is, the API comment is corrected, and ExpiredFileStaffAccessTest pins all three cases.

Verified before merging: 3 passed on the trial-merge. The counter-check has to be inverted for a characterisation test -- these pass on unmodified main by construction, so the question is whether they fail when the boundary moves. Deleting the closing notExpired() from scopeVisibleToClient gives 1 failed / 2 passed, and it is the third case, the one carrying the decision, that falls. File.php overlaps #1726 and Api/FilesController.php overlaps #1727, both already merged, and both are intact in the merged tree. scramble:export reproduces the spec unchanged.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:56:11 -03:00
ignacionelson b9807bf610 Record the comment moderation read boundary as a security fix 
#1745 closes an unauthorised read, so it belongs in the changelog rather than only in the merge log: CHANGELOG.md ships in the zip and renders in the application, and it is where somebody running an installation finds out whether a release is about them.

Written for that reader rather than for the codebase. Permission to moderate comments was letting somebody read them, which is not the same thing, and the entry says what was exposed -- the text, staff-only notes, the client each conversation belongs to, and a visitor's IP -- because "a scoping issue" tells an operator nothing about whether to worry.

It also says who was affected and what to do, which matters more than usual here: no role ProjectSend ships is affected, and the one configuration that is -- a custom role that moderates comments but may open no file -- stops being able to moderate at all. Somebody meeting that on a Monday morning should find the answer in the release notes rather than in a bug report.
 2026-08-28 17:44:10 -03:00
ignacionelson d91cf97bcb Merge pull request #1745 from denkfabrik-li/fix/moderation-view-read-permission 
FilePolicy::view() has two halves for a staff member: one of the three file keys (upload / edit_files / edit_others_files), AND StaffLibraryScope. Every comment surface that spans files narrowed by the library half alone -- VisibleCommentScope::across(), pendingTotal(), and the API's GET /comments/pending. A role holding moderate_comments and no file key at all therefore read, on /comments, every comment in the installation: the text, staff-only notes, the client's name in conversation, and a visitor's IP, while getting a 403 on every file those comments were about. POST /api/v1/comments/{id}/approve was the same door on the write side, and its response carries the comment body, so an id was enough to read one.

The project already states the rule this breaks in four places, including across()'s own docblock -- "a moderation screen is not a way around the visibility model: moderating means deciding about comments you can already see" -- and only the cross-file queries did not ask it.

The cross-file queries now take their files from ViewableFileScope, which is FilePolicy::view() expressed as a query and already in the codebase for exactly this, instead of from StaffLibraryScope, which is only its second half. The permission half becomes a named method there, permitsAnyFile(), because three modules now ask it, and FileCommentPolicy::moderate() asks it in both of its forms. This is the other half of #1698, which library-scoped the same screen: library is not readability.

Verified before merging: tests/Feature/Comments at 180 passed on the trial-merge; with app/ reset and the new test file kept, 5 failed / 2 passed. The two green either way are the right two -- the premise, that the file itself 403s for this viewer, and the guard that a moderator who does hold a file key still moderates the whole installation.

Compatibility was the question worth asking, and it is clean: the only shipped roles holding moderate_comments are Account Manager, which also holds Upload, EditFiles and EditOthersFiles, and System Administrator, which holds everything. No shipped role loses moderation. The only configuration whose behaviour changes is a custom role granting moderate_comments with no file key, which is precisely the leaking one.

This PR also edits docs/api/openapi.json, which #1727 edited too, so the merged result was checked rather than trusted: scramble:export on the merged tree reproduces the committed file byte for byte, with both endpoints' descriptions present.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:43:30 -03:00
ignacionelson 89b3d34c8f Merge pull request #1744 from denkfabrik-li/fix/version-link-duplicate-share-notice 
FileVersions::link() resolves its audience before the merge, and its own comment says the ordering is the whole dedupe: these are the people who could already see both files, so anyone the merge is about to reach for the first time is excluded and gets file_shared from FileSharing::assign() instead. The merge then undid it. moveAssignmentsToRoot() handed every one of the revision's targets to assign() under the comment "firstOrCreate inside, so a target the root already has is a no-op rather than a duplicate notification" -- but firstOrCreate makes the assignment row idempotent, not the three side effects below it. The activity entry, the in-app notification and the digest all ran unconditionally, so a client who already held both files was told a file had been shared with them about a file they had had all along, on top of the file_new_version they were owed. Two notifications for one action, for exactly the people the early resolve exists to protect.

A target the root already holds is now skipped rather than handed to assign(). Nobody is gaining access in that case, so the activity entry would have been as untrue as the notification -- which is the rule copyAssignmentsFrom() states outright for its own case, and why it inserts directly instead of going through FileSharing. The two stale comments are corrected with it.

Deliberately not changed: assign() itself, and so the behaviour ShareNotificationsTest pins, where re-posting an existing assignment through the share endpoint still notifies again. That test says the condition for changing it -- it should stop for files and folders at once, which is the point of them sharing one implementation -- and a version merge is not somebody choosing to share again.

Verified before merging: 10 passed on the trial-merge, 2 failed / 8 passed with app/ reset, and the whole tests/Feature/Files directory at 548 passed. The case where somebody genuinely gains the root still gets file_shared is green either way, which guards against skipping too much. The method was read whole rather than just the hunk: $file->assignments()->delete() still runs for a skipped target, so no row is left dangling and nobody loses reach.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:41:39 -03:00
ignacionelson d09cb602c1 Merge pull request #1743 from denkfabrik-li/fix/read-redirect-covers-every-door 
Three middleware answer before HandleInertiaRequests and so repeat its 302-to-303 upgrade themselves: EnsureSetupIsComplete, EnsureUserIsActive and EnforceTwoFactor. This file has a write case for each. The rule has a second half -- a read still gets a plain 302, because a 303 there is an upgrade nobody asked for -- and that half was checked once, on the deactivation door, under the name "leaves a read alone in every one of those cases". So a change that upgraded reads at the setup door or the two-factor door would have gone through with the suite green and this test still claiming it would not.

One case per door now, as a dataset. The setup case reads a guest-reachable GET for the same reason the write case posts to /timezone: anything behind auth is answered by the guest redirect before EnsureSetupIsComplete ever sees it. No production code changes -- all three doors answer a read with 302 today, which is what the new cases assert.

Verified before merging: 9 passed on the trial-merge, and the mutation counter-check was run here rather than taken from the PR. With EnsureSetupIsComplete answering 303 to everything, this branch's file goes 1 failed / 8 passed and main's version goes 7 passed. The write case for that door stays green under the mutation, which is right: 303 is what a write should get. The mutation itself was confirmed live first, by making the middleware throw and watching the response become a 500 -- a first attempt at it bound no argument and was a silent no-op, which would have looked exactly like the new test failing to notice.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:38:47 -03:00
ignacionelson b7a94d4479 Merge pull request #1742 from denkfabrik-li/fix/file-permissions-test-reads-config 
FILES_WEB_SERVER_READABLE exists so a web server running as a different user can traverse the directories a download lives in. It asked for 0755 from a key that is never consulted: FilesystemManager::createLocalDriver() passes directory_visibility ?? visibility ?? private as the default visibility for directories, and this disk sets visibility to public two lines above with no directory_visibility, so Flysystem reads dir.public and never looks at dir.private. The mode came out 0755 anyway, because 0755 is Flysystem's default for a public directory -- the right answer from the wrong place, which is the kind that stops being right quietly. Adding a directory_visibility to this disk, an ordinary hardening move, or a change to that Flysystem default would have been enough to break the flag silently on exactly the hosts that need it.

Both directory keys are now named, so the intent survives whichever branch Flysystem takes. Nothing widens: the flag-off path is still literally the old configuration, spread rather than ternary, and under the flag 0755 was already the effective mode.

And the test could not have caught it, because it was not testing this configuration: filesDiskWith() restated the shipped branch inline, verbatim down to the 0755, so it kept passing against its own copy however the real one changed. It now requires config/filesystems.php and replaces only the root. Two housekeeping fixes ride along: the scratch root is per parallel worker, the way Tests\TestCase already does it for upload parts, because eight workers sharing one real directory means one worker's afterEach deletes another's tree mid-test; and the tree is cleared before each test as well as after, so a killed run does not poison the next one.

Verified before merging: 3 passed on the trial-merge, and the mutation counter-check was run here rather than taken from the PR. With the shipped dir.public changed to 0750, this branch's test goes 1 failed / 2 passed and main's version of the same file goes 3 passed -- the old one genuinely could not see a change to the shipped configuration.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:34:33 -03:00
ignacionelson fdcdad7fb2 Merge pull request #1741 from denkfabrik-li/fix/zips-queue-check-reachable 
ensure_worker_watches_zips() exists because a worker unit written before zip downloads had their own queue watches default only, and a zip enqueued to zips then waits forever with nothing to say why. It was called from exactly one place: inside the branch that reloads PHP-FPM, nested inside the branch that found a worker unit -- so it ran only when a PHP-FPM unit had been detected. A worker is a different unit from PHP-FPM, and not finding one says nothing about the other: a host running mod_php, or one whose FPM unit is named in a way this script does not recognise, still has a systemd worker that may predate the zips queue, and it got no check and no mention.

The check now also runs in the else branch, where it costs nothing -- its own first line returns immediately unless systemd and a worker unit are both present -- and the worker is restarted after it, paired exactly as the FPM branch pairs them. That pairing is the point: the new --queue argument reaches the worker only when systemd next starts it from ExecStart, and the queue:restart projectsend:update signals cannot deliver it, because that makes a worker pick up new code and it has already run by the time this block is reached. Editing the unit without a restart would leave the operator told that zip downloads were fixed while they still could not finish, which is worse than the silence it replaces: silence sends somebody looking and a success message does not.

Under --no-restart it is said rather than done. Editing a unit file is exactly what that flag asks us not to do, but a worker that cannot finish a zip is broken whether or not we may touch it, and this is the only place that knows to mention it.

Verified before merging: bash -n parses, and the restart block was driven through four host shapes with say, warn, systemctl and the check itself stubbed, on both this branch and main, rather than relying on the transcript in the PR. Before: fpm+worker reached; worker without fpm silent; --no-restart silent; no systemd silent. After: the first two both reached and restarted, --no-restart not reached but said so, no systemd reached and a no-op. That no-op rests on update.sh:330, which returns unless systemd and a worker unit are both present, so it was read rather than assumed.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:32:24 -03:00
ignacionelson ff26fac9c5 Say when the scheduled mail refresh stood aside 
#1739 put the nightly OAuth refresh under the same lock a send holds, which is right -- but standing aside for the lock holder still printed "Refreshed <provider> (<account>)". No token request was made, so the line describes something that did not happen, and scheduler output is read precisely by somebody trying to work out what did.

refreshSerially() now answers whether it refreshed, and the command says which of the two happened. Standing aside is a healthy outcome: somebody else is refreshing this very connection, which slides the token window just as well as doing it again would. It is just not a refresh, and it should not claim to be one.

The existing test for the stand-aside now asserts the output too, and it fails against the old message.

Same reasoning as d8ef21b, which said when the worker check was skipped rather than skipping it quietly.
 2026-08-28 17:27:30 -03:00
ignacionelson a7e883ef70 Merge pull request #1739 from denkfabrik-li/fix/scheduled-mail-refresh-lock 
OAuthCodeFlowBroker::freshAccessToken() serialises refreshes per connection, and its comment says why: both providers rotate the refresh token as they hand out a new access token, so a refresh token is good for exactly one use, and "a worker racing the nightly refresh command" means the slower one spends a token the faster one has already replaced. The provider answers that with invalid_grant, which is the same thing it says about a genuinely revoked grant -- last_error gets written, the settings page turns red, and every admin is told to re-consent a connection that was never broken. RefreshMailOAuthTokensCommand called refresh() directly, outside that lock: it was the racer the comment names rather than a party to the arrangement it describes, and the false alarm landed on the connection the daily run exists to protect.

The command now goes through refreshSerially(), which takes the same lock -- named once, in one place, for both callers -- re-reads the row inside it, and refreshes. Unlike freshAccessToken() it refreshes a token that is still usable, which is the point of the daily run: a delegated refresh token dies of disuse and this keeps the window sliding. The lock is taken rather than waited for, unlike the send path: nobody is standing at a screen for a scheduled job, and a held lock means somebody is refreshing this very connection right now, which slides the window and establishes its health just as well. refresh() stays lock-free, because making it self-locking would deadlock the send path that already holds the lock.

Verified before merging: 24 passed on the trial-merge, 1 failed / 23 passed with app/ reset. PHPStan level 8 clean across app/Modules/Platform/Mail. Adding a method to the MailOAuthBroker interface breaks nothing: OAuthCodeFlowBroker is its only implementer, and MailOAuthBrokers is a registry rather than an implementation.

Known nit, fixed in a follow-up rather than here: when refreshSerially() stands aside because the lock is held, the command still prints "Refreshed <provider> (<account>)".

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:26:24 -03:00
ignacionelson 90009b7029 Merge pull request #1738 from denkfabrik-li/fix/totp-replay-claim-atomically 
TwoFactorService::verify() asked Cache::has(), verified the code, then Cache::put(). Between the read and the write the key is free, so two requests carrying the same code could both be told yes -- which is precisely what the replay guard exists to prevent, and the window an intercepted code has is the whole of its validity either side.

Cache::add() writes only if the key is absent, so of two requests carrying the same valid code exactly one gets true back, and has() is gone: a failed claim is "already used". Verification still runs first, so a wrong code never touches the cache and cannot burn the window for the code the person is about to type correctly. The 90-second claim, the key's shape, and the recovery codes are all unchanged.

Verified before merging: 11 passed on the trial-merge, 1 failed / 10 passed with app/ reset. The existing "a totp code cannot be replayed" test is green either way, because it covers the sequential case, which was never the problem. Being on the authentication path, the wider suites were run too: tests/Feature/Identity and tests/Feature/Auth together, 393 passed.

Cache::add() is only as atomic as the store under it, so every store an installation could realistically run was checked in the vendored framework rather than assumed: database (the default when CACHE_STORE is unset) decides on insertOrIgnore(...) > 0 against the cache table's primary key; redis and memcached have native atomic adds; and the file store takes an exclusive flock before it reads and writes.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:24:28 -03:00
ignacionelson 9508750c60 Merge pull request #1737 from denkfabrik-li/fix/transfer-range-utc-bounds 
resolveTransferRange() builds every boundary in the viewer's zone, deliberately: "last week" should end when their evening does, not at whatever hour UTC midnight falls on for them. Its docblock then claimed the instants "compare against the UTC column directly". They did not -- the query builder formats a Carbon in whatever zone the object carries and discards the offset, so the viewer's midnight reached the database as a UTC string. For Asia/Tokyo the window really began at 2026-08-21T15:00:00Z while the query asked for 2026-08-22 00:00:00: nine hours at each end, both in the same direction, so the first nine hours of the viewer's window were missing from the chart and the last nine hours of somebody else's day were counted into it.

The comparison now converts to UTC, one ->copy()->utc() per boundary. The copy matters: the originals keep the viewer's zone, so the day cursor and the grouping below still put an evening upload on the right bar, which is the half that really is about the viewer's calendar. Every other date filter already goes through LocalDay::start()/end(), which return UTC, which is why the activity log and the download history never had this.

Verified before merging: 20 passed on the trial-merge, 1 failed / 19 passed with app/ reset. Shares DashboardController and its test file with #1722, already merged, so the merged tree was checked -- that PR's visibleToClient change is intact.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:22:37 -03:00
ignacionelson 9c6f4df5bc Merge pull request #1736 from denkfabrik-li/fix/scoped-creator-keeps-client 
A client-scoped staff member with create_clients created a client and lost it in the same request. guardTarget() answers 404 for anything off their roster, and StaffLibraryScope::clients() leaves it out of their list -- so the record existed, was logged, was welcomed by email, and was invisible to the person who made it. store() redirects to the edit page, which is exactly where they landed on a 404. The API twin had the same shape: a scoped token got a 404 from every route that binds the client it had just created.

The new client is now attached to the creator's roster when the creator is client-scoped, on both sides. That is where a client they created belongs -- the roster is the same list assignedClients already uses for everything else they may reach. Unscoped creators gain nothing: they see every client already, and a roster entry would change what assignedClients means for them. Nothing is attached retroactively.

The widening this involves is self-limited: the only thing added is an account the creator just made, which starts with no files, no folders and no group memberships, so assignableClientIds gains nothing to reach. Seats do not move either, since they are counted from active and account_requested.

Verified before merging: 34 passed across both suites on the trial-merge, 2 failed / 32 passed with app/ reset. This is the busiest file set of the series -- it shares ClientsController with #1718 and Api/ClientsController plus the API test file with #1723 -- so the merged result was read rather than trusted: #1718's reassign_candidates gating and #1723's patchCustomFieldValues are both intact alongside it. scramble:export reproduces the committed docs/api/openapi.json byte for byte.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:20:44 -03:00
ignacionelson 2903a1da6d Merge pull request #1735 from denkfabrik-li/fix/editable-once-checkbox 
ClientPortalCustomFields::save() writes '0' for an unticked checkbox, and filled('0') is true in Laravel. isLocked() asked whether anything is stored, so an editable_once checkbox locked itself the first time the client saved the page it sits on, whatever they had chosen. A box they never ticked could then never be ticked, and the one edit the setting promises was spent on a decision they had not made. A text field left empty stores null and stays open; that asymmetry was the bug, and '0' is the absence of a decision in exactly the way null is for every other type.

A checkbox now locks on a stored '1' and nothing else. Every other type keeps filled(). What save() stores is unchanged -- '0' remains a recorded "no", as the API's client create also writes it -- and the behaviour after a real tick is unchanged too: the client still cannot untick it, and the test pinning that is untouched.

Verified before merging: 6 passed on the trial-merge, 1 failed / 5 passed with app/ reset. The editable-once text field test is green either way, which confines the change to checkboxes. The relaxation is safe because the lock is enforced on the write path and not only rendered: isLocked() gates rules(), which drops the field from validation, and save(), which skips it, so the ticked-to-unticked direction stays closed server-side.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:18:38 -03:00
ignacionelson c11cb3cc63 Merge pull request #1734 from denkfabrik-li/fix/quota-message-inherited-default 
ClientStorageUsage::quotaMb() exists because a client's own storage_quota_mb of 0 does not mean "unlimited" -- it means "no quota of their own", and the site default is what is then enforced. Both chunked-upload quota checks enforced the resolved limit through quotaBytes() and then printed the raw column in the rejection, so a client with no quota of their own and a site default of 1 MB was told "This upload would exceed your storage quota of 0 MB." That is every client who was never given a quota, including every self-registered one, and the sentence appears at the one moment somebody is trying to find out what their limit is.

Both now print quotaMb(), which is what the check enforced. The API's single-request upload already did exactly this for the same sentence, so the three copies agree. The enforcement itself is untouched -- only the number in the message changes -- and the unlimited case never reaches these branches, because quotaBytes() > 0 guards them.

Verified before merging: 16 passed on the trial-merge, 2 failed / 14 passed with app/ reset. The "a client with a quota of their own still sees their own number" test is green either way. The string itself is unchanged, so no locale file needs anything.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:17:17 -03:00
ignacionelson 5117511946 Merge pull request #1732 from denkfabrik-li/fix/public-preview-log-debounce 
FileThumbnailController::preview() writes at most one FilePreviewed row per viewer per file per five minutes, because watching a video is a single deliberate act that the browser turns into dozens of Range requests. Its docblock ended by naming the route where the same act happens without an account -- PublicGroupsController::preview -- and that route logged unconditionally. Five requests for the same public file wrote five rows where the signed-in twin wrote one, so one visitor watching one clip buried the public half of the activity log, which is the half an operator reads to see what the outside world is doing.

The window moves into a shared PreviewLog, next to PreviewKind, which those two routes already share for the same reason. Keying is unchanged for a signed-in viewer. An anonymous visitor has no account to key on, so the request IP stands in -- the same substitute ApiServiceProvider's rate limiter makes for an unauthenticated caller. It is a cache key with a five-minute life and never reaches the log, which keeps its own decision about recording an IP.

Downloads are deliberately untouched and stay one row per download: each is a transfer, and DownloadAllowance::used() counts those rows to enforce a per-file cap, so swallowing one would hand out free downloads.

The limit this leaves open, since the IP is a stand-in and not an identity: two anonymous visitors behind one address share a key, so within five minutes the second one's view of the same file is not recorded. That is the same trade the signed-in side has always made per account, and the alternative is the row-per-Range-request this fixes.

Verified before merging: 24 passed across the public-preview and thumbnail suites on the trial-merge, which also confirms this co-exists with #1725 -- the two share both controllers and change different methods in each. With app/ reset and PreviewLog deleted, 1 failed / 9 passed. The signed-in route's existing debounce tests pass unchanged, which is what says the shared class did not move that side. request()->ip() honours the trusted-proxy configuration, so a forged X-Forwarded-For cannot defeat the window from outside.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:13:05 -03:00
ignacionelson b6f4770795 Merge pull request #1731 from denkfabrik-li/fix/zip-build-failure-hygiene 
BuildZipDownloadJob already draws this line in its write-failure branch: "What the requester sees stays generic: a libzip string means nothing to them and can name a server path. An operator needs the opposite, so the reason goes to the log instead." Thirty-seven lines below it, the catch-all around the whole build stored $e->getMessage() in the row the requester polls -- and ZipDownloadsController hands that column straight back to whoever asked, clients included. A client asking for an archive of a file whose disk is no longer configured read "Disk [a-disk-that-is-not-configured] does not have a configured driver." verbatim. The reason now goes to the log with the exception class, and the row carries the same kind of sentence fail() already uses.

Two more in the same method. tempnam() creates the file, and $tempFiles[] was appended only after the copy finished, so every throw in between left a zip-src- file in the system temp directory that nothing ever removed; it is now registered the moment it exists. And the copy itself was unchecked -- a copy that stops early is a truncated member added to the archive as though it were the file, so the build reports ready and the recipient gets something that opens and is wrong. stream_copy_to_stream and the flushing fclose are both checked now, and both handles close on every path.

Deliberately not changed: comparing the copied byte count against files.size, which would fail perfectly good archives whenever that column is stale; the write-failure branch and its wording; and the skipped-files reporting, which still says which files and why, so only the catch-all went generic.

Verified before merging: 37 passed on the trial-merge, 2 failed / 35 passed with app/ reset. The leak was confirmed at the consuming end rather than inferred -- ZipDownloadsController:169 returns the error column to the requester.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:05:30 -03:00
ignacionelson 037439e1f2 Merge pull request #1730 from denkfabrik-li/fix/provisioning-over-deleted-address 
The unique index on users.email spans soft-deleted rows -- AvailableEmailRule is built on exactly that -- so a deleted account keeps its address until erasure removes the row. The registration form learns this from validation. The machine paths have no form to validate: a directory or an identity provider hands over an address and ClientProvisioning::provision() inserts it, so a client deleted earlier signing in through a provider that may auto-provision got a QueryException, and what the person met was a 500 in the middle of their sign-in. Same shape through LDAP at POST /login.

Both provisioners now ask ClientProvisioning::addressIsFree() first and refuse. The social flow reuses the refusal it already gives every other identity it cannot provision -- "There is no account here for that address." -- which is also all a stranger should learn: whether an address was once an account here is not the provider's to publish. The LDAP flow falls through to the ordinary failed sign-in.

The deleted account is deliberately not resurrected and not linked. Restoring one because a directory still lists the address is a decision for a person, not a side effect of somebody signing in -- and a linking shortcut here would be an account takeover. Everything about an address belonging to a live account is untouched.

Verified before merging: 47 passed on the trial-merge, 2 failed / 45 passed with app/ reset. addressIsFree() queries withTrashed(), the same span as the unique index it protects, so the check and the constraint agree. Worth noting that both new warning lines record the email address, which is consistent with what these paths already log but is PII in the application log.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:03:34 -03:00
ignacionelson 6b99e37d01 Merge pull request #1729 from denkfabrik-li/fix/api-surface-by-route 
Two places asked "is this the API?", and each got it wrong in the opposite direction.

EnsureCapability asked $request->expectsJson(). Whether a feature exists in this installation's edition is a property of the installation, not of what the caller is willing to parse: the same capability-gated API route answered 403 capability_unavailable to Accept: application/json and a bare 404 to Accept: */*, which is curl's default, while routes/api.php promises the 403 in as many words. The mirror image was worse -- an Inertia visit to a capability-gated web screen accepts JSON, so it took the API branch and announced the feature by name, where the whole point of the 404 is that an unavailable feature is absent rather than teased.

ProblemDetails asked $request->is('api/*'). Two staff pages live under that prefix -- the API dashboard at /api and the OpenAPI reference at /api/docs, both from routes/web.php -- so a signed-out visitor to /api/docs got a 401 problem+json telling them to send a Bearer token instead of the login redirect every other page gives.

One question now, asked once, in App\Support\ApiSurface: under the API prefix, and not part of the web middleware group. The group is what actually separates the two surfaces -- sessions, cookies and CSRF on one side, tokens on the other -- and it keeps answering correctly for a future /api/v2 without being edited. An unmatched path has no route to ask and stays the API's answer, which is what the existing "a missing API route is a problem+json 404" test pins. EnsureStaff keeps its expectsJson() check: there the question really is about the caller.

Verified before merging: the discriminator was checked in the running application rather than assumed -- /api/docs and /api resolve to [web, auth, staff], /api/v1/files to [api, auth:sanctum, api-active, staff-token, token-can:...]. 12 passed on the trial-merge; with app/ reset and ApiSurface deleted, 3 failed / 9 passed, every new test and no old one. Wider suites green: tests/Feature/Api 239 passed, tests/Feature/Platform 485 passed. scramble:export reproduces main's docs/api/openapi.json byte for byte. Worth recording that the blast radius here is the shape of a refusal and never whether one happens: both call sites run after authentication and authorization.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:02:05 -03:00
ignacionelson f676e09bb2 Merge pull request #1728 from denkfabrik-li/fix/expiry-timezone-drift 
The edit screen is given a file's expiry as a calendar date read back in the viewer's own zone -- deliberately, or "a file set to expire on the 12th reopens showing the 11th". Every save posts that date back, touched or not, and update() derived a fresh instant from it every time. So the expiry drifted by the difference between two people's zones on any other edit: a file set from Pacific/Auckland moved 19 hours later the moment somebody in Buenos Aires renamed it, and moved again on the next save from a third zone. A file could quietly outlive the expiry somebody set for it, through an edit that had nothing to do with expiry.

The instant is now re-derived only when the posted date differs from the one the form was given, compared against the same string through a named pair: expiryDateFor() renders it, expiryInstant() reads it back, and the edit screen calls the render half so the two cannot drift apart. What a changed date means is unchanged -- still the end of that day in the zone of whoever changed it. bulkUpdate() needs nothing: its expiry is an explicit set / clear / no_change action, so an untouched expiry is never posted at all.

Verified before merging: 22 passed on the trial-merge, 1 failed / 21 passed with app/ reset. The "a real change still lands in the editor's zone" and "clearing still clears" tests are green either way. Edge cases walked: a posted date against no stored expiry still sets it, and a posted null against a stored null leaves the column alone rather than writing.

Reported and fixed by @denkfabrik-li.
 2026-08-28 17:00:16 -03:00
ignacionelson eb3d6e321d Merge pull request #1727 from denkfabrik-li/fix/api-expiry-end-of-day 
FilesController::expiryInstant() exists because a calendar day ends where the person naming it lives: the web form posts a bare YYYY-MM-DD, which Eloquent would otherwise store as midnight UTC, so "expires on the 12th" would cut the file off partway through the 11th for anyone in the Americas. PATCH /api/v1/files/{id} took the same field, validated it as a date, and stored it exactly as it arrived -- so the same value that meant end-of-the-12th on the web meant start-of-the-12th over the API, and earlier still for a caller west of Greenwich.

A bare YYYY-MM-DD now means the end of that day in the caller's timezone, through the same LocalDay::end() the web path uses. A value carrying a time is unchanged: that is an instant the caller named on purpose, the API can express one where a date input cannot, and it is stored as it arrives. null still clears the expiry, and the validation rule and permission gate are untouched.

Note for the release notes: this lengthens the life of a file whose expiry an existing integration sets with a bare date, by up to a day. That is the correct meaning and the one the web has always had, but it is a behaviour change for callers who were relying on the old one.

Verified before merging: 19 passed on the trial-merge, 1 failed / 18 passed with app/ reset. The timestamp and clearing tests are green either way. The bare-date branch is gated on a strict ^\d{4}-\d{2}-\d{2}$ match, so nothing else takes it. scramble:export on the merged tree reproduces the committed docs/api/openapi.json byte for byte.

Reported and fixed by @denkfabrik-li.
 2026-08-28 16:58:34 -03:00
ignacionelson d89807b237 Merge pull request #1726 from denkfabrik-li/fix/rendition-cleanup-independent 
FileDiskCleanup::delete() wrapped two deletions in one try: the original upload, on whatever disk the row names, and every cached rendition, which is always on the local files disk. Storage::disk() throws outright for a name with no configured driver -- precisely the state the original's disk is in whenever this fails at all -- so the catch swallowed it and the renditions were never reached. Nothing looks for them afterwards: OrphanFileScanner skips the rendition directories on purpose, as derived artifacts rather than orphaned uploads. A file whose external disk had been removed or renamed therefore kept every cached copy of itself indefinitely on the disk that still worked, including the client-facing ones, which for a shared image may be the only copies anyone ever generated.

The two attempts are now separate, each with the tolerance the class was written for: a storage failure still never turns a delete click into a 500, and the warning is still the whole report.

Also corrected: File::booted() justified deferring the byte removal with "the worst case is bytes left on disk with no row, which OrphanFileScanner already finds and reports". That is not this path -- the row is soft-deleted, and knownPaths() counts a trashed row's path as claimed, deliberately, so a scan never offers to double-adopt a file still inside its erasure grace period. The comment now says what actually happens, which is that FileDiskCleanup's warning is the only record.

Verified before merging: 8 passed on the trial-merge, 1 failed / 7 passed with app/ reset.

Reported and fixed by @denkfabrik-li.
 2026-08-28 16:56:47 -03:00
ignacionelson 7ff2674e4f Merge pull request #1725 from denkfabrik-li/fix/rendition-written-atomically 
Both thumbnail routes treat "the file exists" as "the rendition is cached", and nothing ever invalidates one: RenderedImageCache::flush() runs on ImageRenderingChanged, which no code in core raises. Whatever sits at the path is what every later viewer gets. ThumbnailGenerator::generate() encoded straight onto that path, so a render that died partway -- a full volume, a killed worker -- left a half-written file that was then served as the rendition indefinitely, and two requests rendering the same file at once encoded into the same path together.

Write side: the image is written beside its destination and renamed into place. rename() within a directory is atomic and replaces what is there, so the path holds either the previous rendition or a complete new one, and the loser of a race leaves a whole image rather than a mixture of two. Renditions always cache on the local files disk and the generator is handed $disk->path(), so both files are on the same filesystem and the atomicity is real. Read side: an empty file is not a rendition, so both routes replace one rather than serve it -- writing through a temporary file means core can no longer create that state, but an installation that ran an older version can already have it on disk and nothing else will ever clear it.

The cache itself is unchanged: a non-empty rendition is still reused without further checks, because decoding every cached image on every request to prove it is intact would cost the cache its point. The RenderingImage seam still fires before the encode.

Verified before merging: 14 passed on the trial-merge, 2 failed / 12 passed with app/ reset. The third test, about the generator's own temporary file, passes either way and the PR says so rather than leaving it to be found.

Reported and fixed by @denkfabrik-li.
 2026-08-28 16:55:29 -03:00
ignacionelson 262cb2457a Merge pull request #1723 from denkfabrik-li/fix/api-patch-custom-fields 
Api\ClientsController::update() states the rule eighteen lines above the bug: "PATCH semantics, unlike the web form which always submits every field: an absent key means 'leave alone', not 'clear'." Every column obeyed it. The custom fields did not -- they went through saveCustomFieldValues(), which is create()'s pass: it walks every field there is and writes null for the ones the request did not carry. A PATCH naming one field emptied all the others, with nothing in the response to say so and no second copy of the value anywhere.

The write pass is still shared but is now entered two ways: create() keeps writing every field, and update() writes only the fields the request named. Creating a client is deliberately unchanged -- it is not a partial update, and a checkbox nobody ticked is a recorded "no" rather than an absent row. Clearing a field by naming it with an empty value still clears it, and the validation rules are untouched.

Verified before merging: 23 passed on the trial-merge, 1 failed / 22 passed with app/ reset. The two guard tests -- a named empty value still clears, create still records every field -- are green either way, so the write path was not simply switched off. The keys reaching whereIn() are stripped to real field ids by validateCustomFieldValues() before they get there. scramble:export re-run on the merged tree produces a docs/api/openapi.json identical to main's, so the published spec does not move.

Reported and fixed by @denkfabrik-li.
 2026-08-28 16:47:40 -03:00
ignacionelson a285f86b93 Merge pull request #1722 from denkfabrik-li/fix/portal-dashboard-visible-files 
DashboardController::clientDashboard() built its own whereHas('assignments') query instead of using File::scopeVisibleToClient -- "the single source of truth for client file access", as that scope's own docblock puts it. The copy reproduced the assignment half and stopped there, so the page disagreed with the portal it introduces, in both directions. Over: the scope ends in notExpired(), so an expired file was gone from /my-files and refused on download while the dashboard went on counting it and printing its name. Under: a file in a folder shared with the client, a file the client uploaded through the portal themselves, and a revision -- which owns no assignment row and inherits its original's recipients through SharingIdentity -- were all missing from the count and the list.

The hand-rolled query is gone and the scope is used, one query object cloned for the count exactly as before. groups_count and the storage figures are untouched: they answer different questions and have their own tests.

Verified before merging: 19 passed on the trial-merge, 2 failed / 17 passed with app/ reset. The existing "clients get the portal dashboard with their own numbers" test is unchanged and green either way, so a directly assigned live file counts as it always did. PHPStan level 8 clean on the changed file.

Reported and fixed by @denkfabrik-li.
 2026-08-28 16:16:49 -03:00
ignacionelson bc68a24ef5 Merge pull request #1721 from denkfabrik-li/fix/api-dashboard-activity-log-scope 
ApiUsage::recentActions() read the activity log without ActivityLogScope::apply(). It was the only ActivityLog::query() outside ActivityLogger and AccountEraser that skipped it. Its only boundary was view_actions_log -- the permission ActivityLogScope's own docblock says "is not the whole answer for a client-scoped staff member", because a log row carries the subject's name. The Client Manager system role is client_scoped and ships with that permission, so this was the default configuration and not an exotic one: the same person who gets a 403 on a file and an empty /activity read that file's name off /api?all=1.

ApiUsage now takes ActivityLogScope and applies it to the recent-actions query, on both sides of the install-wide branch rather than only in the install-wide arm -- the own-actor filter already stays inside what the scope allows, and a boundary that exists in only one arm of an if is one refactor away from not existing. The token inventory, request counts and endpoint table keep ApiUsageScope alone: those rows are about the viewer's own credentials rather than library content.

Verified before merging: 17 passed on the trial-merge and 1 failed / 16 passed with app/ reset. The two tests guarding against narrowing further than /activity does -- a viewer's own actions stay whole, an unscoped viewer's feed is unchanged -- are green either way. ActivityLogScope::apply() wraps its conditions in a single where(Closure), so it composes with the origin and actor_id filters around it without a precedence trap, and ApiUsage is never constructed with new, so the added dependency is wired by the container everywhere.

Reported and fixed by @denkfabrik-li.
 2026-08-28 16:14:57 -03:00
ignacionelson 1644d634d5 Merge pull request #1720 from denkfabrik-li/fix/group-reach-expired-file 
groupReachesNoFurther() decides whether a client-scoped staff member may edit a group, by asking whether anything shared with it sits outside their library. f1b35cc9 settled that answer for deleted files: start from the live row, because a deleted file is not reach, because nobody can reach it. An expired file is the same case and was not covered. File::scopeVisibleToClient ends in notExpired(), so the moment a file expires it leaves every member's /my-files and the download answers 403 -- but it also leaves files(), where its absence reads as "outside my library". The group then became unmanageable for good: the rep could not add anyone, and could not undo their own membership change either.

The reach query now skips expired files as it already skips deleted ones. File::scopeVisibleToClient is unchanged -- what expiry does to a scoped viewer's library was settled deliberately in c8078f65, and this is about what counts as reach, not about what anyone may open. The folder half needs nothing, because folders do not expire.

The limit this leaves open, stated rather than implied: a membership added while a file was expired outlives the expiry, so if somebody later clears expires_at the client reaches a file that was outside the actor's library when the decision was made. f1b35cc9 leaves exactly the same opening for a file restored from the trash, and closing either would mean the guard weighing rows nobody can currently reach.

Verified before merging: this changes the file half of the same method #1719 changed the folder half of, so the merged tree was read rather than trusted -- both halves now skip expired files consistently. 29 passed on the merged tree, 1 failed / 28 passed with app/ reset. The "an expired file does not excuse a live one that is still out of reach" test is green either way.

Reported and fixed by @denkfabrik-li.
 2026-08-28 15:59:24 -03:00
ignacionelson abbe9a3acc Merge pull request #1719 from denkfabrik-li/fix/group-reach-subtree 
StaffLibraryScope::groupReachesNoFurther() asks whether anything shared with a group sits outside the viewer's library, and its docblock says the folder half covers "the folders whose subtrees it can browse". It compared the folder ids the assignment names and stopped there. But a folder shared with a group hands its members the whole subtree -- File::scopeVisibleToClient matches on folder placement, and a folder is visible to a client when it or an ancestor is shared with them -- so the guard passed on a subtree it had never looked into. A scoped rep could add their own client to a group holding a folder they own, and a stranger's file inside it went to that client, and then into the rep's own library, because files() is "own uploads plus everything my clients can see". That is exactly the widening the first test in the file exists to refuse.

The folder half now walks each assigned folder's subtree via subtreeFolderIds(), and the files inside it are checked too: a folder can be in the library while a file in it is not, since somebody else's upload into a folder this rep owns is neither their own nor their clients'. Expired files are skipped for the reason deleted ones are -- membership grants nobody access to one, and something nobody can reach is not reach.

Verified before merging: 27 passed on the trial-merge, and 2 failed / 25 passed with app/ reset to main. The "subtree wholly inside the library stays manageable" test is green either way, which is what says the guard was tightened rather than closed. subtreeFolderIds() walks a materialised path prefix, so it is one query per assigned folder with no recursion.

Reported and fixed by @denkfabrik-li.
 2026-08-28 15:51:33 -03:00
ignacionelson 3dc407a777 Merge pull request #1718 from denkfabrik-li/fix/reassign-candidates-scope 
reassign_candidates is the delete dialog's picker -- every active account in the installation, by name and role label -- and it was narrowed by nothing. Two lines above it on the clients index sits the listing itself, narrowed through StaffLibraryScope with a comment saying why. A client-scoped rep with manage_clients therefore read the name and role of every client in the installation, including the ones they can reach nothing of. The can('delete_clients') filter meant to hide the picker runs in React, which decides what is rendered, not what is sent.

The client half of the candidate list now goes through the same StaffLibraryScope as the listing beside it, and each screen sends the picker only to a viewer holding the delete permission it exists for. Staff accounts are not narrowed, here or anywhere else in the application. Privacy settings keeps the whole installation deliberately: that picker sets the erasure default stored once for everybody, behind edit_settings, so narrowing it by whoever happens to be editing would store the wrong answer.

Verified before merging: the four new tests pass on the trial-merge and go 3 failed / 16 passed with app/ reset to main, so they are testing the fix and not something else. Every call site of the changed candidates() signature was checked.

Reported and fixed by @denkfabrik-li.
 2026-08-28 15:46:17 -03:00
ignacionelson d8ef21bb6a Say when the worker check was skipped rather than skipping it quietly 
ensure_worker_watches_zips reads the unit file with `systemctl show -p
FragmentPath`, and an empty answer meant an immediate, silent return. The
common cause is a mistyped --worker: systemd does not know the unit, the
check never runs, and the operator finishes the update believing their
worker was inspected.

Which produces precisely the outcome the function exists to prevent. Its
own comment says a worker that does not watch the zips queue finishes no
zip downloads while cheerfully sending every email, and that nothing says
why. Skipping the check in silence is a quieter way to arrive there.

It now warns, names the consequence, and says what to check. The
read-only case is separated out too: a unit file somebody else owns
cannot be repaired, but it can still be read, so a worker that is missing
the queue is diagnosed rather than passed over.

Worth recording why this was looked at. The portal session found a deploy
script that had printed `next run` followed by nothing for its whole
life, because `systemctl show` answers an unknown property with an empty
value and a zero exit -- a line always blank is worse than no line, since
somebody believes a check is being performed. FragmentPath here is
correct, verified against a real unit; the failure was the same shape one
step further on, in what an empty answer was taken to mean.
 2026-08-28 14:33:47 -03:00
ignacionelson 479dc61d2d Move branding into core, and leave white-labelling behind 
Logo and watermark belonged in the private package for one reason: that
is where they were written. Nothing about them needs a hosted platform,
and an installation wanting its own mark on the pages it serves is the
ordinary case rather than the exotic one. They are core's now, and every
installation has them.

Hiding "Powered by ProjectSend" did not come. That is what a hosted
customer pays for, and its gate is not a capability key but the absence
of the code: cloud-modules keeps the listener, so an installation without
that package holds the column and has nothing able to read it. Flipping
an edition variable buys nothing, which was true before and stays true.
Core renders the switch where Capability::AttributionHide is held and has
no route that can save it -- there is a test asserting exactly that, which
fails the day white-labelling quietly becomes free.

The migrations move with their original filenames on purpose. A Cloud
tenant already ran them under those names, so Laravel skips them there
and the table and its data are untouched; a fresh install or a community
one runs them from here for the first time.

What got better on the way rather than merely moving:

The watermark listeners take core's real RenderingImage and
ResolvingImageRendering instead of duck-typed `object` payloads, and the
tests construct the genuine events rather than anonymous stand-ins that
imitated their shape. The package had to do it that way -- it builds with
no host present -- so three PHPStan ignore entries existed to describe
what the type system could not see. They are gone.

ModuleBoundaryTest asserted "branding is cloud-only, and the suite runs as
community", which was never what it was testing. It now reads the
capability off the route and subtracts it, so the invariant holds for
whichever module is installed.

The 43 branding strings arrived in all sixteen locales from the package's
own catalogues rather than being retranslated, and the package's are
pruned to the one string it still uses.

A hosted plan without branding subtracts branding.customize and
attribution.hide from the instance's environment. The row is never
deleted by that: a downgrade is usually an expired card rather than a
decision, and wiping somebody's artwork over a billing event is a loss
they would find weeks later with no way to know what it used to be.
Hiding reverses; deleting does not.
 2026-08-28 13:27:10 -03:00
ignacionelson 530f30606d Let a plan take a capability away, and split branding from white-labelling 
Groundwork for moving Branding out of the private package. Two changes,
both about who decides what an installation may do.

An edition grants capabilities; an operator may now take some away, via
PROJECTSEND_CAPABILITIES_DISABLED. Subtractive only, and that asymmetry is
the whole design: a variable that could *add* would put the hosted
edition's proprietary screens one line of .env away on every self-hosted
install, which is not a gate at all. So the list is intersected with what
the edition already allows and can only make the answer smaller.

This is not the plan tier core has always refused to invent. There are
still no billing tiers here to key off -- the objection config/api.php
makes about rate limits stands. It is the operator stating a fact about
this installation, exactly as PROJECTSEND_PLATFORM_MAX_STAFF_USERS does
for seats: the platform knows what it sold, the installation is told and
enforces. Unknown keys are ignored rather than fatal, because the variable
outlives both the plan that wrote it and the release that named the key,
and refusing to boot over a stale one would be an outage on upgrade day.

The registry takes the list as a constructor argument rather than reading
config itself, which keeps it a value object testable without an
application -- the failure that surfaced it was a unit test with no
container.

And branding.customize is now both editions, with the white-label half
split into attribution.hide, which stays Cloud-only. Dressing an
installation in its own logo is not a hosted concern; taking ProjectSend's
name off somebody's public pages is what a hosted customer pays for. The
gate on the second is not the key but that the only code able to answer
"hide it" ships in the private package, so flipping an edition variable
buys nothing.

EnsureCapabilityMiddlewareTest had to pick a new Cloud-only example for
the second time -- branding after users.manage. It now uses
storage.managed, and records what to ask if it ever needs a third.

The code move itself is the next commit; nothing user-visible changes yet,
because the screens still live in cloud-modules.
 2026-08-28 13:11:57 -03:00
ignacionelson afc2c74617 Say who depends on the activity log never being pruned 
last_staff_login_at is a MAX() over activity_log, and the docblock
already said the log is never pruned. It did not say that anything
depends on it. Something does now: the hosted platform warns, pauses and
finally removes a free instance nobody has signed in to, counting from
this field.

So retention or pruning added to activity_log would break nothing here --
every test would pass, the field would keep answering, and old
installations would quietly start looking dormant to the process that
deletes them. That is the shape of failure worth naming in advance,
because the person adding a retention policy would have no reason to look
at this file.

Same note as the one on SeatAllowance's counting rules and on
ManagedStorageBackend::describe(): an assumption with a reader outside
this repository is a contract, and the place to record it is where
somebody would otherwise change it.
 2026-08-28 12:11:29 -03:00
ignacionelson d62c62f788 Let an installation say which build it is 
A version string is a decision somebody made. A commit is a fact, and the
two come apart exactly when it matters: an image built from the tag and
one built from the branch that tag sits on carry the same version and
different code. The fleet spent a day reporting 2.2.0 from images that
were not the released 2.2.0, and nothing inside any of them could have
said so -- which is why 2.2.1 was cut for a control plane rather than for
users.

So every artifact now carries config/build.php, written by
build-release.sh and never committed, and projectsend:status reports it
as `build`: the commit, the ref it describes to, the channel and the
build time.

All four are null on a source checkout, because there is no such file
there. That is the honest answer rather than a missing one -- "I was not
built" and "I will not say" are different facts, and this file's whole
null discipline exists because a reader that cannot tell them apart
eventually acts on the wrong one. An empty string is treated as no
answer for the same reason: a build step that ran and produced nothing
must not read as "answered" to anything checking presence.
 2026-08-28 11:57:43 -03:00
denkfabrik-li 7be81d3586 Tell the admins the mailbox is dead, even when a send noticed first 
The daily refresh doubles as the health check for a connected OAuth
mailbox, and its own docblock says why that matters: a grant can die
silently, "which for a portal whose password-reset mails ride on this
connection must surface as a warning, not as a support ticket weeks
later".

It decided whether to warn by reading last_error -- but the send path
writes that column too. OAuthCodeFlowBroker::refresh() records the
failure and notifies nobody, and freshAccessToken() reaches it from every
send. So on an installation that actually sends mail, the send lands
first, the command reads the column as "already told them", and the
warning never goes out. last_error is cleared only by a successful
refresh, which a dead grant never has, so it never goes out again either.

Measured on main, one dead grant, two orders:

  nobody sends, command first   1 notification, then quiet   correct
  a password-reset mail first   0 ... 0 ... 0                never

The alarm worked on installations that were not using the mailbox and
failed on the ones that were.

The anti-nag rule is not the problem and does not change. The problem is
that last_error answers "is this broken", which any writer may set, while
the command needs "have the admins been told", which only the notifier
can. The table's own comment shows the conflation -- one column described
as "what the settings page's warning and the admin notification read".

So the notification gets its own column. broken_notified_at is stamped
when the command notifies, and cleared wherever last_error is cleared: a
successful refresh, a disconnect, a changed client id. The three call
sites go through MailOAuthConnection::clearFailure() rather than nulling
two columns each, because a connection left marked "already told them"
while healthy would go quiet the next time it died -- the same bug in a
new place.
 2026-08-28 14:41:38 +02:00
denkfabrik-li 92f50fdb85 Read a comment's author even after the account is deleted 
`author_id` is cascadeOnDelete and the cascade never fires, because users
are soft-deleted: the row behind a deleted commenter is still there and
the column still points at it. The plain relation handed back null
anyway, and every caller invented its own meaning for that absence.

Measured on main, one staff member's staff-only comment, before and after
the account is deleted:

  /comments screen        Dana Staff / staff  ->  Dana Staff / guest
  the file's own thread   Dana Staff / staff  ->  Dana Staff / guest
  GET /api/v1/.../comments      type staff    ->  type client
  filter author_type=staff            1 row   ->  0 rows
  search "Dana"                       1 row   ->  0 rows
  unfiltered                          1 row   ->  1 row

Three surfaces, three different wrong answers, each next to a name that
stayed correct -- so a row can read "Dana Staff" and "guest" at once. A
moderator filtering for staff comments does not see a staff comment that
is sitting in the list in front of them.

This is the author half of what #1717 fixed for client_context_id, and
DeletedClientThreadTest's docblock already describes both columns.

The fix is the relation, not the five call sites: author() reads a
deleted account, which is what authorName() already reached for by hand.
The resource, the filter and the search then need no change at all. The
two authorType() copies now ask author_id rather than the relation --
which after this answers the same either way, and is the rule
isFromGuest() and authorName() already follow.

Nothing that decides who may read a comment goes through this relation.
VisibleCommentScope and FileCommentPolicy both compare author_id
directly, so no visibility widens.
 2026-08-28 14:24:03 +02:00
denkfabrik-li 27c289a4d6 Let a password reset know where the account's credentials live 
Two accounts reach the same reset with opposite needs, and it treated
both as "write a hash and hope".

A provider-created account is told, on the Connected accounts screen, to
"set a password first, then disconnect Google" -- and doing it changed
nothing, because nothing ever set auth_source back to Local.
AccountConversion is the only writer, and that is an administrator. So the
screen went on asking for something that had already been done, and the
person could not release their last provider without help.

AuthSource states the rule that closes this: `social` means the account
came into existence without anybody choosing a password, and, in as many
words, "a social account may later set a real password". A reset by
emailed token is where somebody does. The screen's has_local_password prop
is literally auth_source === Local, so the write is what completes the
sentence it prints.

A directory account is the opposite case and gets the opposite answer.
isDirectoryAccount() means the local hash is not consulted at all, so the
reset reported success and left the person with a password that cannot
sign them in -- including when the directory it points at is gone, which
is exactly when somebody reaches for a reset. It is refused now, with the
reason, and nothing about the account moves: taking one off its directory
is an administrator's decision through AccountConversion, not a side
effect of a reset.

The refusal sits where the token has already been validated, not where the
link is asked for. That endpoint answers "A reset link will be sent if the
account exists" to everybody on purpose, and refusing there would tell a
stranger both that an address is an account and how it signs in. Throwing
before the write also leaves the token unspent, since PasswordBroker
deletes it after the callback returns.
 2026-08-28 14:01:24 +02:00
denkfabrik-li 5e60d2ef88 Say what expiry does to a client-scoped staff member's library 
File::isExpired() documents the rule the application is supposed to
follow: once past, the file is hidden from clients and the public site
"but staff keep full access to view, download, and manage it".

The second half is not true of a client-scoped staff member.
StaffLibraryScope::buildFiles() builds their library as their own uploads
union what each assigned client may see, and that second half runs
through File::scopeVisibleToClient, which ends in notExpired() -- a
client-side rule. Measured on main, with a rep holding one client and a
file the administrator uploaded and shared with that client:

    before expiry   in_library true    GET .../download -> 200
    after expiry    in_library false   GET .../download -> 403

    the rep's own expired upload                  in_library true
    an unscoped administrator, same expired file  in_library true

Api\FilesController says it the same way -- "Only the client branch of
the visibility rules drops them" -- which reads as though a staff caller
is unaffected, when a client-scoped one is reached through that very
branch.

This does not change that behaviour. c8078f65 weighed exactly this and
decided against it: widening it would mean a library query that keeps
expired rows, and scopeVisibleToClient is the single source of truth for
client file access, the highest-stakes function to go changing for a
dashboard widget. The widget was relabelled instead.

That decision lives in a commit message and in one widget's label.
Nothing in the code said it, and the docblock nearest the rule went on
promising the opposite -- which is how the next person re-derives "staff
keep full access" and widens something.

So both comments now state the boundary and why it is where it is, and
ExpiredFileStaffAccessTest makes it executable: an unscoped staff member
keeps an expired file, a client-scoped one keeps their own expired
upload, a client-scoped one loses a client's file when it expires.

Not changed: scopeVisibleToClient, StaffLibraryScope, and the
expired-files widget. If the boundary should move, that is a separate
conversation and a separate change.

Counter-check inverted, since these pass on unmodified main by
construction -- there is no behaviour fix for them to prove. What they
have to do is fail if the boundary moves, so the mutation is the widening
itself. Deleting the closing notExpired() call from scopeVisibleToClient
turns the file red, 1 failed / 2 passed, and it is the third case, the
one carrying the decision, that falls.

Suite 2108 passed / 2 skipped, 11416 assertions, PHPStan level 8 clean.
Measured on base 06c364d2, where main itself is 2105 / 2.
 2026-08-28 06:56:09 +02:00
denkfabrik-li 21cae2acb1 Stop a version link telling people about a file they already had 
FileVersions::link() resolves its notification audience before the merge,
and says why:

    RESOLVED BEFORE THE MERGE, and the ordering is the whole dedupe:
    these are the people who could already see both files, so anyone the
    merge below is about to reach for the first time is excluded here and
    gets file_shared from FileSharing::assign() instead. Resolve it
    afterwards and every newly-added client receives two emails about one
    action.

The merge then undoes it. moveAssignmentsToRoot() hands every one of the
revision's targets to FileSharing::assign(), under a comment claiming
that firstOrCreate makes a target the root already has a no-op. It makes
the assignment row idempotent; the three side effects under it --
activity entry, in-app notification, digest -- run unconditionally.

Measured on main:

    client already holds the root and the revision, then both are linked
      file_shared      (Report)     <- wrong, they have had it all along
      file_new_version (Report v2)  <- right
      assignment rows on the root: 1

    client holds only the revision, then both are linked
      file_shared      (Report)     <- right, the merge does hand it over

Two notifications for one action, for exactly the people the early
resolve was meant to protect.

So a target the root already holds is skipped rather than handed to
assign(). Nobody is gaining access in that case, and the activity entry
would be as untrue as the notification. copyAssignmentsFrom() directly
below already states that rule for its own case, which is why it inserts
directly instead of going through FileSharing. Both stale comments are
corrected with it.

Not changed: FileSharing::assign() itself, and so the behaviour
ShareNotificationsTest pins -- re-posting an existing assignment through
the share endpoint still notifies again. That test names the condition
for ever changing it, "it should stop being sent for both at once", and
that is a decision about files and folders together. This is narrower: a
version merge is not somebody choosing to share again, and it already
had a stated intent to send exactly one notification.

Three cases in ShareNotificationsTest -- the target already on the root,
the target gaining it, and a group already on the root. Reverting
FileVersions alone leaves 2 failed / 8 passed in that file; the middle
case passes without the fix, because it guards against skipping too much
rather than against the duplicate notice.

Suite 2108 passed / 2 skipped, 11415 assertions, PHPStan level 8 clean.
Measured on base 06c364d2, where main itself is 2105 / 2.
 2026-08-28 06:56:09 +02:00
ignacionelson 2029309126 Release 2.2.1 2026-08-28 01:52:41 -03:00
denkfabrik-li defe488391 Ask about the zips queue on every path that could answer it 
ensure_worker_watches_zips() exists because a worker unit written before
zip downloads had their own queue watches 'default' only, and a zip
enqueued to 'zips' then waits forever with nothing saying why. It is
called from exactly one place: inside the branch that reloads PHP-FPM,
nested inside the branch that found a worker unit.

So it runs only when a PHP-FPM unit was detected. Driving the restart
block through four host shapes, with everything it touches stubbed:

  systemd + fpm + worker      reached, restarted
  systemd + worker, no fpm    silent
  --no-restart                silent
  no systemd at all           silent

The second line is the one that matters. A worker unit is a different
service from PHP-FPM, and not finding one says nothing about the other: a
host running mod_php, or one whose FPM unit is named in a way this script
does not recognise, can still have a systemd worker that predates the
zips queue. That host gets no check and no mention.

The check now runs in the else branch too, where it costs nothing -- its
own first line returns immediately unless systemd and a worker unit are
both present -- and the worker is restarted after it, paired exactly as
the FPM branch pairs them. That pairing is the point rather than a
flourish: the new --queue argument reaches the worker only when systemd
next starts it from ExecStart. The queue:restart that projectsend:update
signals cannot deliver it, because that makes a worker pick up new *code*
and it has already run by the time this block is reached, so the worker
came back on the old command line. Editing the unit without the restart
would leave the operator told that zip downloads were fixed while they
still could not finish -- worse than the silence it replaces, since
silence sends somebody looking.

Under --no-restart it is said rather than done: editing a unit file is
exactly what that flag asks us not to do, but a worker that cannot finish
a zip is broken whether or not we are allowed to touch it, and this is the
only place that knows to mention it.

Same four shapes afterwards:

  systemd + fpm + worker      reached, restarted
  systemd + worker, no fpm    reached, restarted
  --no-restart                not reached, but said so
  no systemd at all           reached, no restart (returns immediately)

No test: the suite cannot drive a shell script that restarts services.
bash -n parses, and the harness above is the evidence.
 2026-08-28 06:45:49 +02:00
ignacionelson d83d2d9acb Translate the three strings the last release cycle added 
Two seat counters and one folder-delete refusal, in all sixteen locales.
Additive only: nothing already in a catalogue was reordered or reworded,
so the diff is three lines per file.

Polish, Czech and Russian get three plural forms where the English has
two. Those languages inflect a noun by the number in front of it -- one
case for 2-4, another for 5 and up -- and the framework's selector picks
between three segments for them, so writing only the English pair would
have produced "5 pliki" where it has to be "5 plikow". Verified through
trans_choice at 1, 3 and 7.
 2026-08-28 01:45:07 -03:00
denkfabrik-li fc5651faad Check the read half of the redirect rule at every door, not one 
Three middleware answer before HandleInertiaRequests and so have to
repeat its 302→303 upgrade themselves: EnsureSetupIsComplete,
EnsureUserIsActive and EnforceTwoFactor. This file has a write case for
each, and the rule has a second half -- a read still gets a plain 302,
because a 303 there would be an upgrade nobody asked for.

That half was checked once, on the deactivation door, under a name that
said otherwise: "leaves a read alone in every one of those cases". The
setup door and the two-factor door were not covered at all, so a change
that upgraded reads at either of them would have gone through with the
suite green and this test's name still claiming it would not.

Both are covered now, as a dataset with one case per door. The setup case
reads a guest-reachable GET for the same reason the write case posts to
/timezone: anything behind `auth` is answered by the guest redirect before
EnsureSetupIsComplete sees it.

No production code changes; today all three doors answer a read with 302,
which is what the new cases assert. Demonstrated by mutation rather than
reversion: making EnsureSetupIsComplete upgrade every redirect to 303
fails this file (1 failed / 8 passed) and passes the old one (7 passed).
 2026-08-28 06:40:54 +02:00
denkfabrik-li b838036a9a Set the directory permission Flysystem actually reads 
FILES_WEB_SERVER_READABLE asks for 0755 on the directories a download has
to be traversed through, and asks for it from a key that is never
consulted.

FilesystemManager::createLocalDriver passes
`directory_visibility ?? visibility ?? private` to
PortableVisibilityConverter::fromArray() as the default visibility for
directories. This disk sets `visibility` to public two lines above, and no
`directory_visibility`, so directories are public and the converter reads
`dir.public`. The configuration names only `dir.private`.

The mode is 0755 regardless, because 0755 is Flysystem's default for a
public directory -- the right answer from the wrong place. Adding
`directory_visibility` to this disk, or a change to that default, is all
it would take for the flag to stop doing what it says. Measured on main,
with the flag on:

  dir.private 0755 → 0750   directory stays 0755   (nothing reads it)
  dir.public  0755 → 0750   directory becomes 0750 (this is the key)

Both are named now, so the intent survives either way round.

FilePermissionsTest could not have caught this, because it was not testing
this configuration. filesDiskWith() restated the shipped branch inline,
verbatim down to the 0755, so it went on passing against its own copy
however the real one changed. It now requires config/filesystems.php and
replaces only the root, which is what makes the mutation above visible to
it.

Two more things in the same helper, both about the suite rather than the
subject: the scratch root is per worker now (Tests\TestCase does the same
for upload parts, and eight workers sharing one directory means one
worker's afterEach deletes another's tree mid-test), and it is cleared
before each test as well as after, so a killed run does not poison the
next one.
 2026-08-28 06:40:54 +02:00
denkfabrik-li 5a9133bb07 Give a download's presigned URL a minute rather than an hour 
StoredFileResponse hands external storage a presigned URL for an hour,
whatever the delivery is for. That URL is a bearer credential: whoever
holds it fetches the file without passing any of the caller's checks
again, and it outlives them. A download cap spent in the meantime, an
expires_at that falls inside the hour, an assignment withdrawn -- none of
them reach it, and nothing here can revoke one. It is also forwardable,
which the local path is not: X-Accel-Redirect authorises one response to
one request.

The two deliveries do not need the same window, so they no longer share
one.

A download has to survive being followed -- a redirect and a request --
which a minute covers with room to spare. An object store checks the
signature when the request arrives rather than while it runs, so a
transfer that starts inside the window finishes however long it takes.

A preview keeps the hour, because it is watched rather than fetched: the
player holds the URL and issues a Range request every time somebody seeks
past the buffer, so a minute would break playback of anything longer than
a minute. The class docblock now says that this is the trade being made,
instead of leaving it in a single number.

Two tests, one per window. Without the fix the download link is an hour
long.
 2026-08-28 06:40:53 +02:00
denkfabrik-li 02eafb473b Refresh a mailbox on the schedule under the lock a send would hold 
freshAccessToken() serialises refreshes per connection, and its comment
says why: both providers rotate the refresh token as they hand out an
access token, so the token is good for exactly one use, and "a worker
racing the nightly refresh command means the slower one spends a token the
faster one has already replaced. The provider answers that with
invalid_grant, which is the same thing it says about a genuinely revoked
grant: last_error gets written, the settings page turns red, and every
admin is told to go and re-consent a connection that was never broken."

The nightly refresh command called refresh() directly, outside that lock.
It was the racer the comment names, not a party to the arrangement it
describes.

It now goes through refreshSerially(), which takes the same lock -- named
once, in one place, for both callers -- re-reads the row inside it, and
refreshes. Unlike freshAccessToken() it refreshes a token that is still
usable, which is the point of the daily run: a delegated refresh token
dies of disuse and this keeps the window sliding.

The lock is taken rather than waited for, unlike the send path. Nobody is
standing at a screen for a scheduled job, and a held lock means somebody
is refreshing this very connection right now -- which slides the window
and establishes its health just as well as doing it again would.

One test: with the lock held, the command sends no token request and
leaves the connection untouched. Without the fix it spends the refresh
token the holder is already spending.
 2026-08-28 06:40:53 +02:00
denkfabrik-li 674781e57a Claim a TOTP code atomically instead of checking then writing 
verify() asked Cache::has(), verified, then Cache::put(). Between the read
and the write the key is free, so two requests carrying the same code
could both be told yes -- which is exactly what the replay guard exists to
prevent, and the window an intercepted code has is the whole of its
validity either side.

The claim is now the answer: Cache::add() writes only if the key is
absent, so of two requests carrying the same valid code exactly one gets
true back. That is the same mechanism, for the same reason, as the
preview log's debounce -- "Cache::add is the whole mechanism: it writes
only if the key is absent ... without a read-then-write race between two
of them".

Verification still happens first, so a wrong code never touches the cache
and cannot burn the window for the code the person is about to type
correctly.

One test, modelling the interleaving it is about: the winner's claim has
landed, and the loser's has() answers from before that write. Without the
fix the loser is signed in.
 2026-08-28 06:40:52 +02:00
denkfabrik-li f39ad46dd6 Leave the caches update.sh's own update command needs to see 
INSTALL.md tells an operator to cache routes, views and events once, and
promises: "You only run these once: projectsend:update notices they are in
place and rebuilds them for you after every update."

It cannot, for anybody who updates with update.sh. The script wipes
bootstrap/cache/*.php while replacing the application files, and
UpdateInstallation::warmCaches() decides what to rebuild by asking
file_exists() on those very paths -- forty lines later. Every installation
looks like one that never cached anything.

Measured in a copy of the tree, the two orderings:

  wiping everything, as the script does it
    → "Cleared the compiled configuration, events, routes and views."
    → bootstrap/cache is empty afterwards

  keeping the route and event caches
    → "Rebuilt the route, event and view caches — they were in place before."
    → routes-v7.php and events.php are back

So the site quietly loses route, event and view caching on every update,
and the operator is never told.

The wipe now names what it removes rather than taking the directory:

  - packages.php and services.php, because they must not survive the swap:
    they name the old release's package providers, and the first artisan
    run after the copy would try to load classes this version no longer
    ships.
  - config.php, for a sharper reason. It is read at every boot, so leaving
    it means projectsend:update reads the *previous* release's version out
    of it. Measured with a doctored version inside a cached config: the run
    said "Re-applied 2.2.0" while the release on disk was 9.9.9, recorded
    that old version as the one applied, and ran the migrations under the
    old configuration. With it removed: "Updated from 2.2.0 to 9.9.9".

The route and event caches stay, since neither is read at boot -- both are
arrays of class names, consulted when a route is matched or an event
dispatched -- and projectsend:update clears them itself moments later.

Removing config.php here would have taken the command's "a cached
configuration was found" warning with it, since it warns about what it
finds. The script now says it, in the same words, at the moment it removes
the file.

No test: the suite covers the command's decision (UpdateCommandTest pins
the whole rewarm matrix) and cannot run a shell script that replaces an
installation. The measurements above are the evidence; bash -n parses.
 2026-08-28 06:40:51 +02:00
denkfabrik-li a1773cad5e Count a shared folder's contents as reach, not just the folder 
groupReachesNoFurther() asks whether anything shared with a group sits
outside the viewer's library. Its docblock says the folder half covers
"the folders whose subtrees it can browse". It compares the folder ids the
assignment names and stops there.

A folder shared with a group hands its members the whole subtree --
File::scopeVisibleToClient matches on folder placement, and a folder is
visible to a client when it or an ancestor is shared with them. So the
guard passed on a subtree it had never looked into.

Measured on main: a scoped rep's own folder, a subfolder somebody else
created inside it, and that person's file in the subfolder.

  parent in the rep's library     true
  subfolder in it                 false
  the file in it                  false
  add their own client to a group holding the parent   302, allowed
  the client can then reach the file                   true

And because files() is "own uploads plus everything my clients can see",
the file lands in the rep's own library on the next request. That is the
widening this guard exists to refuse -- the first test in the file is
called "a scoped staff member cannot widen their own library through a
group".

The folder half now walks each assigned folder's subtree, and the files
inside it are checked too: a folder can be in the library while a file in
it is not, since somebody else's upload into a folder this rep owns is
neither their own nor their clients'. Expired files are skipped for the
reason the deleted ones are -- membership grants nobody access to one.

Three tests: the subfolder case, the stranger-file case, and a subtree
wholly inside the library, which stays manageable. The first two go red
without the fix.
 2026-08-28 06:40:51 +02:00
denkfabrik-li 17fc9ff4cb Compare the transfers window against the column's own timezone 
resolveTransferRange() builds every boundary in the viewer's zone, which
is right and deliberate: "last week" should end when their evening does.
Its docblock then claims the instants "compare against the UTC column
directly". They do not. The query builder formats a Carbon in whatever
zone the object carries and drops the offset, so the viewer's midnight
arrives at the database as a UTC string.

For Asia/Tokyo, measured:

  the instant the window really starts   2026-08-21T15:00:00+00:00
  what the query asked for               2026-08-22 00:00:00

Nine hours at each end, in the same direction: the first nine hours of
the viewer's window are missing from the chart, and the last nine hours
of somebody else's day are counted into it. Every zone east or west of
UTC gets a chart that is quietly wrong at both edges, which is worse than
one that is obviously wrong.

The comparison now converts; the day cursor a few lines below does not,
because that half genuinely is about the viewer's calendar and is what
puts an evening upload on the right bar.

One test, in Asia/Tokyo, with an upload in the first hour of the viewer's
window. Without the fix it is missing from the chart.
 2026-08-28 06:40:50 +02:00
denkfabrik-li 776d3d99f4 Put a client on the roster of the scoped staff member who created them 
A client-scoped staff member with create_clients creates a client and
loses it immediately. guardTarget() answers 404 for anything off their
roster, and StaffLibraryScope::clients() leaves it out of their list -- so
the record exists, is logged, is welcomed by email, and is invisible to
the person who made it. store() redirects to the edit page, which is where
they land:

  POST /clients        → 302 → /clients/4
  on_creator_roster    → false
  GET /clients/4/edit  → 404
  clients listed       → ["Mine"]     the new client is not there

Their own roster is where a client they created belongs, so it is attached
there. An unscoped creator gains nothing: they see every client already,
and a roster entry would change what assignedClients means for them.

The API twin does the same, for the same reason -- a scoped token gets a
404 from every route that binds the client it just created.

Three tests: the scoped creator can open and list the client, an unscoped
creator gains no roster entry, and the API twin behaves like the web. The
first and third go red without the fix.
 2026-08-28 06:40:50 +02:00
denkfabrik-li 9ddd39c41d Refuse to provision over a deleted account's address instead of crashing 
The unique index on `email` spans soft-deleted rows -- AvailableEmailRule
is built on exactly that, so a deleted account keeps its address until
erasure removes the row. The registration form learns this from
validation. The machine paths have no form: a directory or an identity
provider hands over an address and provision() inserts it.

Measured on main, a client deleted last week signing in through a
provider that may auto-provision:

  GET /auth/google/callback → 500   (QueryException, unique constraint)

Same shape through LDAP at POST /login. Nothing is created, nothing is
signed in, and what the person meets is a server error.

Both provisioners now ask ClientProvisioning::addressIsFree() first and
refuse. The social flow already has a refusal for an identity it cannot
provision -- "There is no account here for that address." -- which is also
all a stranger should learn: whether an address was once an account here
is not the provider's to publish. The LDAP flow falls through to the
ordinary failed sign-in.

Deliberately not resurrecting the deleted account. Restoring one because
a directory says the address exists is a decision for a person, not a
side effect of somebody logging in.

Two tests, one per path: the sign-in is refused, nothing is created, and
the trashed row is still trashed. Both go red without the fix.
 2026-08-28 06:40:50 +02:00
denkfabrik-li 19c449ee20 Stop an editable-once checkbox locking before anybody ticks it 
save() writes '0' for an unticked checkbox, and filled('0') is true in
Laravel -- so isLocked(), which asks whether anything is stored, locked
the field the first time the client saved the page it sits on, whatever
they had chosen. A box they never ticked could then never be ticked, and
the one edit the setting promises was spent on a decision they had not
made.

A text field left empty stores null and stays open. That asymmetry is the
bug: '0' is the absence of a decision, which is what null means for every
other type.

So a checkbox locks on a stored '1' and nothing else. Everything else is
unchanged, including the existing case of a client ticking the box and
then being unable to untick it.

Two tests: an unrelated save leaves the box open and the tick that follows
still lands and locks it; and an editable-once text field behaves exactly
as before. Without the fix the first goes red.
 2026-08-28 06:40:49 +02:00
denkfabrik-li 4b998cda92 Fail a zip build without handing the requester the server's reason 
The write-failure branch already draws the line and says why: "What the
requester sees stays generic: a libzip string means nothing to them and
can name a server path. An operator needs the opposite ... so the reason
goes to the log instead." Thirty-seven lines below it, the catch-all
around the whole build stored $e->getMessage() in the row the requester
polls. Measured, a client asking for an archive of a file on a disk that
is no longer configured was told:

  "Disk [a-disk-that-is-not-configured] does not have a configured driver."

The reason now goes to the log with the exception class, and the row
carries the same kind of sentence fail() already uses.

Second, the temp files. tempnam() creates the file, and $tempFiles[] was
appended only after the copy had finished -- so every throw in between (a
disk that will not resolve, a stream that will not open) left a zip-src-
file in the system temp directory that nothing ever removes. It is now
registered the moment it exists.

Third, in the same method: the copy itself was unchecked. A copy that
stops early is a truncated member added to the archive as though it were
the file, so the build reports ready and the recipient gets something that
opens and is wrong. Both the copy and the fclose that flushes it are
checked now, and both handles close on every path.

Two tests: the failure message names nothing about the server, and a build
that throws mid-copy leaves no temp file behind. Both go red without the
fix.
 2026-08-28 06:40:49 +02:00
denkfabrik-li 4164678ebc Delete a file's renditions even when its own disk cannot be resolved 
FileDiskCleanup wraps both deletions in one try. The first is the original
upload, on whatever disk the row names; the second is every cached
rendition, always on the local files disk. Storage::disk() throws outright
for a name with no configured driver -- which is the state the original's
disk is in whenever this fails at all -- so the catch swallowed it and the
renditions were never reached.

Nothing looks for them afterwards. OrphanFileScanner skips the rendition
directories on purpose (they are derived artifacts, never orphaned
uploads), so a file whose external disk had been removed or renamed kept
every cached copy of itself, indefinitely, on the disk that was working.

The two attempts are now separate, each with the same tolerance the class
was written for: a storage failure still never turns a delete click into a
500, and the warning is still the report.

While here, the comment in File::booted() that justifies deferring the
byte removal claimed "the worst case is bytes left on disk with no row,
which OrphanFileScanner already finds and reports". Not on this path: the
row is soft-deleted, and knownPaths() counts a trashed row's path as
claimed -- deliberately, so a scan never offers to double-adopt a file
still inside its erasure grace period. The comment now says what actually
happens.

One test: a file whose disk cannot be resolved loses its renditions. It
goes red without the fix, next to the existing test that the delete itself
still succeeds.
 2026-08-28 06:40:48 +02:00
denkfabrik-li fc758c701a Write a rendition through a temporary file, and never serve an empty one 
Both thumbnail routes treat "the file exists" as "the rendition is
cached", and nothing ever invalidates one: RenderedImageCache::flush()
runs on ImageRenderingChanged, which no core code raises. Whatever is at
the path is what every later viewer gets.

ThumbnailGenerator encoded straight onto that path. A render that died
partway -- a full volume, a killed worker -- left a half-written file
that was then served as the rendition for good, and two requests
rendering the same file at once encoded into one path together.

It now writes beside the destination and renames into place. rename()
within a directory is atomic and replaces what is there, so the path is
either the previous rendition or a complete new one, and the loser of a
race leaves a whole image rather than a mixture of two. The temporary
file is removed on the way out either way.

The read side gets the other half: an empty file is not a rendition, so
both routes replace one rather than serve it. Writing through a temporary
file means this state can no longer be created here, but an installation
that ran an older version can already have it on disk, and nothing else
will ever clear it.

Three tests: an empty rendition is replaced on the signed-in route and on
the public one, and a successful render leaves nothing half-written
behind. Without the fix the first two go red; the third is about the fix's
own temporary file and passes either way.
 2026-08-28 06:40:48 +02:00
denkfabrik-li f2b705beee Keep an upload's parts until its bytes are stored 
complete() holds a lock whose comment promises "the lock's TTL releases
the claim if a completion dies mid-flight, so a later retry still works".
A retry has nothing to work from but the parts, and assemble() unlinked
each one inside the loop that read it -- so everything that can fail
afterwards took the retry with it.

Measured on main, with a disk refusing the write (the case the guard forty
lines further down was written for, found against a real GCS bucket):

  first complete  → 422, 0 parts left, the half-written copy left behind
  retry           → 422 "Upload is incomplete: missing parts."

For good: listParts() is empty, so no later attempt can ever succeed, and
the client has to send the whole file again. The abandoned copy sat in the
session directory until the sweeper came round.

The parts now go when abort() clears the session directory -- which
already ran on success -- and a failure deletes only the half-written copy
it made. The cost is temp space: peak usage during assembly is the whole
file twice over rather than the file plus one part. The docblock says so.

Also checked while here: every read and every write in the concatenation.
A failing fwrite is loud in practice, since Laravel's error handler turns
the warning into an ErrorException, but loud there is a 500 carrying a PHP
message where this method's other storage failure is a sentence the person
uploading can act on. A short write arriving without a warning would be
worse: the byte count and the checksum describe the buffer that was read,
so an unchecked one records a truncated file with a checksum matching
bytes that were never stored.

Two tests: the retry after a refused write now succeeds, and a temporary
directory that refuses writes (/dev/full, skipped where it does not exist)
fails the upload with this method's own message. Without the fix both go
red.
 2026-08-28 06:40:47 +02:00
denkfabrik-li 250e8664d3 Stop a client PATCH clearing custom fields it never mentioned 
update() states the rule eighteen lines above the bug: "PATCH semantics,
unlike the web form which always submits every field: an absent key means
'leave alone', not 'clear'." Every column obeys it. The custom fields did
not, because they went through create()'s pass, which walks every field
there is and writes null for the ones the request did not carry.

Two fields filled, a PATCH naming one:

  status         → 200
  named field    → "Robin"
  the other one  → null      (was "ATU12345678")

Nothing says so in the response, and there is no other copy of the value.

The write pass is now shared but entered two ways: create() keeps writing
every field, since a new client has no values and a checkbox nobody ticked
is a recorded "no"; update() writes only the fields the request named.

Three tests: the untouched field survives, a named empty value still
clears, and create still records every field. Without the fix the first
goes red.
 2026-08-28 06:40:47 +02:00
denkfabrik-li 640c5db591 Stop an expiry moving because somebody else saved the file 
The edit form is given a file's expiry as a calendar date, read back in
the viewer's own zone -- deliberately, so a file set to expire on the 12th
does not reopen showing the 11th. Every save posts that date back, whether
or not anybody touched it, and update() derived a fresh instant from it
every time.

So the expiry drifts by the difference between two people's zones on any
other edit. A date set from Pacific/Auckland stores 2026-09-12T11:59:59Z;
a colleague in UTC-3 opens the file, sees the same 12th, renames it, and
the file now expires at 2026-09-13T06:59:59Z -- 19 hours later, with
nobody having gone near the date.

The instant is now re-derived only when the posted date differs from the
one the form was given, compared against the same string through a named
pair: expiryDateFor() renders it, expiryInstant() reads it back. The edit
screen uses the same method it is compared against, so the two cannot
drift apart.

bulkUpdate() needs nothing: its expiry is an explicit set/clear/no_change
action, so an untouched expiry is never posted in the first place.

Three tests: the rename leaves the instant alone, a real change still
lands in the editor's own zone, and clearing still clears. Without the fix
the first goes red.
 2026-08-28 06:40:46 +02:00
denkfabrik-li e1cd010f9d Give an API expiry date the same meaning the web gives it 
FilesController::expiryInstant exists because a calendar day ends where
the person naming it lives: the web form posts a bare YYYY-MM-DD, and
storing that as it arrives would cut a file off at midnight UTC -- "expires
on the 12th" ending partway through the 11th for anyone in the Americas.

The API takes the same field, validates it as a date, and stores it raw:

  web  → 2026-09-12T23:59:59+00:00   (end of the day, as the docblock means)
  API  → 2026-09-12T00:00:00+00:00   (raw)

Same value, same field, same file, two meanings -- and the earlier of the
two is a file that dies at the start of the day it was promised.

A bare date now means the end of that day in the caller's timezone, as it
does on the web. A value carrying a time is unchanged: it is an instant
the caller named on purpose, the API can express one and a date input
cannot. The endpoint's docblock says both, so the OpenAPI document does
too.

Three tests: the day, the timestamp, and clearing. Without the fix the
first goes red.
 2026-08-28 06:40:46 +02:00
denkfabrik-li c2dd2c758a Debounce the public preview log the way the signed-in one already is 
FileThumbnailController::preview() writes at most one FilePreviewed row
per viewer per file per five minutes, because a browser turns one video
into a long tail of Range requests against the same URL. Its docblock
names the anonymous route as the place the same act happens without an
account -- and that route logs unconditionally.

Measured: five requests for the same public file, five
PublicFilePreviewed rows, against one for the signed-in twin. One visitor
watching one clip buries the public half of the activity log, which is
also the half an operator reads to see what the outside world is doing.

The window is now a shared PreviewLog, next to PreviewKind, which the two
preview routes already share for the same reason. Keying is unchanged for
a signed-in viewer; an anonymous one has no account to key on, so the
request IP stands in -- the same substitute the API's rate limiter makes
for an unauthenticated caller. It is a cache key with a five-minute life
and never reaches the log, which keeps its own decision about recording an
IP (ActivityLogger::shouldRecordIp, Setting::DownloadIpLogging).

Three tests: the replay is one row, two visitors are two rows, and the
window is per file. Without the fix the first goes red.
 2026-08-28 06:40:45 +02:00
denkfabrik-li 9d4b096c19 Narrow the reassignment picker to what a viewer may see 
`reassign_candidates` is the delete dialog's picker: every active account
in the installation, by name and by role label. The same list is shared
on the clients index, the users index, both edit screens and privacy
settings, and it was narrowed by nothing.

Two lines above it on the clients index sits the listing itself, narrowed
through `scope->clients($viewer)` with a comment saying why: "a
client-scoped staff member is not shown the name and email of somebody
they can reach nothing of". The picker beside it handed over every client
in the installation, plus every staff account and its role name. The
filter by `can('delete_clients')` happens in React, which decides what is
rendered, not what is sent.

So the client half of the candidate list goes through the same
StaffLibraryScope as the listing, and each screen sends the picker only to
a viewer holding the delete permission it exists for. Staff accounts are
not narrowed -- they are not narrowed anywhere else either -- and an
unscoped viewer's list is unchanged, because StaffLibraryScope::clients()
returns every client for them.

Privacy settings keeps the whole installation on purpose: that picker sets
the erasure default stored once for everybody, behind edit_settings, so
narrowing it by whoever happens to be editing would store the wrong
answer. The parameter is nullable for that one caller, and the docblock
says so.

Four tests. Without the fix three go red; the fourth is the guard that an
administrator still sees every active account.
 2026-08-28 06:40:45 +02:00
denkfabrik-li 763777d282 Say which permission a bulk edit was actually missing 
Two different things stop a selected file being changed, and bulkUpdate()
reported both as the first one.

Files dropped by the Gate::allows('update') filter are ones the staff
member may not edit at all. A file that survives the filter and still
changes nothing is a different case: it was editable, and every field they
asked to change was one their role does not let them set -- expiry,
download limit, categories, each behind its own permission, exactly as the
single-file editor treats them.

Measured with edit_files but without set_file_expiration_date, three files
they own, expiry the only change: "0 of 3 selected files were updated. The
rest were skipped because you don't have permission to edit them." They
own all three and editing is precisely what they may do, so the sentence is
both wrong and unactionable.

The two cases now have their own sentences. The existing string is kept
for the case it describes -- every skip a file they may not edit -- so its
sixteen translations stay in use. The new one covers a field permission,
and covers a mixture of both reasons, since "permission to make those
changes" is true either way.

The new key is English only; a locale without it falls back to English,
which is a translated-but-wrong sentence traded for an untranslated
correct one.

Three tests: each reason on its own, and the mixture. Without the fix the
first and third go red.
 2026-08-28 06:40:44 +02:00
denkfabrik-li f424fe5365 Decide what is an API request from the route, not from the caller's headers 
Two places asked "is this the API?" and got it wrong in opposite ways.

EnsureCapability asked $request->expectsJson(). Whether a feature exists
in this installation's edition is a property of the installation, not of
what the caller is willing to parse, so the same route answered
differently per header: `Accept: application/json` got the 403
`capability_unavailable` routes/api.php promises, `Accept: */*` -- curl's
default -- got a bare 404 `not_found`. The mirror image is worse: an
Inertia visit to a capability-gated *web* screen accepts JSON, so it got
403 with Laravel's default error body, naming the exception class, where
the point of the 404 is that an unavailable feature is absent rather than
teased.

ProblemDetails asked $request->is('api/*'). Two staff pages live under
that prefix -- the API dashboard at /api and the OpenAPI reference at
/api/docs, both registered in routes/web.php -- so a signed-out visitor to
either got 401 problem+json, "Send a valid API token in the Authorization
header as \"Bearer <token>\"", instead of the login redirect every other
page gives them.

Both now ask App\Support\ApiSurface: under the API prefix, and not part of
the `web` middleware group. The group is what actually separates the two
-- sessions and CSRF on one side, tokens on the other -- and it keeps
answering correctly for a future /api/v2 without being edited. An
unmatched path has no route to ask, which is the API's answer anyway: a
404 under its prefix is one it should describe in its own format, and the
existing test for that stays green.

Three tests, in the two files that already own these rules. Without the
fix all three go red.
 2026-08-28 06:40:44 +02:00
denkfabrik-li cd8da6a117 Name the quota a client is actually held to when an upload is refused 
Both chunked-upload quota checks resolve the limit through
ClientStorageUsage::quotaBytes(), which falls back to the site default
when a client has no quota of their own -- and then print
`$user->storage_quota_mb` in the rejection. For every client who was never
given an explicit quota that column is 0, so the message reads "This
upload would exceed your storage quota of 0 MB." at the one moment
somebody is trying to find out what their limit is.

The API's single-request upload already prints
`$this->storageUsage->quotaMb($user)` for the same sentence
(Api/FilesController.php:208). The two chunked copies now do the same.

Three tests: the inherited default is named at session creation and again
at completion, and a client with a quota of their own still sees their own
number. Without the fix the first two go red, the third stays green.
 2026-08-28 06:40:43 +02:00
denkfabrik-li db1dd71f3c Stop an expired file locking a group shut for a scoped staff member 
groupReachesNoFurther() asks whether anything shared with a group sits
outside the viewer's library. `f1b35cc9` established the shape of the
answer for deleted files: start from the live row, because "a deleted file
is not reach, because nobody can reach it".

An expired file is the same case. Membership grants nobody access to it --
File::scopeVisibleToClient ends in notExpired(), so it has left every
member's /my-files and the download answers 403 -- but it is equally gone
from files(), where its absence reads as "outside my library". The group
then locks for a scoped staff member: they cannot add a member, cannot
rename it, and cannot remove their own client again.

So the reach query skips expired files as it already skips deleted ones.
Expiry is reversible where deletion is not, and that needs no special
handling: the guard asks what is reachable at the moment somebody is added
or removed, and the file counts again the moment it stops being expired.

Not changed: File::scopeVisibleToClient, whose treatment of expiry was
settled deliberately in c8078f65. This is about what counts as reach, not
about what a scoped viewer may open.

Two tests, next to the deleted-file pair they mirror: the lockout, and the
half that must not soften -- a live out-of-reach file is still reach with
an expired sibling next to it. Without the fix the first goes red.
 2026-08-28 06:40:43 +02:00
denkfabrik-li c8de16101f Gate the comment moderation surfaces on reading, not just on the library 
FilePolicy::view() has two halves for staff: one of the three file keys
(upload / edit_files / edit_others_files), AND StaffLibraryScope. Every
comment surface that spans files narrowed by the library half alone.

A role holding moderate_comments and no file key therefore got a 403 on
every file in the installation while reading every comment written about
them on /comments: the text, staff-only notes, the client name a
Clients-visibility comment carries, and a visitor's IP address. The API
queue answered the same way, and approving through it hands the body back
in the response, so it was a reading door as well as a writing one.

The class says this is not supposed to happen -- across()'s own docblock
("a moderation screen is not a way around the visibility model"), the
route comment on /comments ("the list itself is still narrowed by
VisibleCommentScope, so holding the permission does not widen what a
viewer may read"), and routes/api.php ("reading and writing a comment is
gated by 'may see this file', the same three keys the file endpoints
use"). FileCommentPolicy::view() enforces it for a single comment, by
running the file's own gate first. Only the cross-file queries did not.

So they now take their files from ViewableFileScope, which is
FilePolicy::view() expressed as a query, instead of from StaffLibraryScope,
which is only its second half: across(), pendingTotal() and the API's
pending list. The permission half moves into a named method on that class,
since three modules now ask the same question.

FileCommentPolicy::moderate() gets it too, in both forms. Its row form is
otherwise unchanged -- the library check still runs by file id, so a
comment on a soft-deleted file behaves exactly as before.

No system role changes behaviour: Account Manager and System Administrator
are the two that ship with moderate_comments, and both hold upload. What
changes is a hand-built role that holds moderation and nothing else.

Seven tests. Without the fix, five go red; the other two are the premise
(that the viewer really is refused the file itself) and the guard that a
moderator who may read files still moderates the whole installation.

docs/api/openapi.json regenerated for the one changed description.
 2026-08-28 06:40:42 +02:00
denkfabrik-li cb53120779 Show the portal dashboard the files a client can actually open 
clientDashboard() restates the assignment half of
File::scopeVisibleToClient in a whereHas of its own. The scope is the
single source of truth for client file access and ends in notExpired(),
which the copy leaves off, so the two disagree in both directions.

Over: an expired file stays counted and keeps its name on the dashboard
after /my-files has stopped listing it and the download answers 403. Under:
everything that reaches a client another way is missing -- a file inside a
folder shared with them, a file they uploaded through the portal
themselves, and a revision, which owns no assignment row at all and
inherits its original's recipients through SharingIdentity.

Replaced by the scope itself, which is what /my-files runs. The existing
test for the page is unchanged and still passes: a directly assigned,
unexpired file counts exactly as before.

Two tests, one for each direction. Without the fix both go red.
 2026-08-28 06:40:42 +02:00
denkfabrik-li 84e9f6e2fe Scope the API dashboard's recent actions to what the viewer may read 
ApiUsage::recentActions() is the only ActivityLog query outside
ActivityLogger and AccountEraser that does not run through
ActivityLogScope::apply(). Its whole boundary is view_actions_log -- the
permission whose own scope class says, in as many words, that it "is not
the whole answer for a client-scoped staff member".

The Client Manager system role is client_scoped and ships with that
permission, so this is the default configuration. Such a viewer opening
/api?all=1 reads the fifteen most recent API log rows for the entire
installation, each with its subject_name: the names of files and clients
they get a 403 on. /activity, the download history and the dashboard's
recent-activity widget all narrow the same rows; the API dashboard was
missed.

The scope is applied on both sides of the install-wide branch. The
own-actor filter for the narrow view already stays inside what the scope
allows, and a boundary that exists in only one arm of an `if` is one
refactor away from not existing.

Three tests: the scoped viewer sees only the entry about a file in their
library, their own actions stay whole even when the subject is outside it,
and an unscoped viewer's feed is unchanged. Without the fix the first goes
red; the other two are green either way and guard against narrowing too far.
 2026-08-28 06:40:41 +02:00
ignacionelson 06c364d29a Report storage, health and what packages loaded in projectsend:status 
Five more facts for whatever watches an installation from outside the
container, and one seam so a package can add its own.

Storage is the one that was about to be wrong. It is summed from the rows
that record it, not measured on the volume: measuring the directory was
correct until external storage went live and silently stopped being, since
an upload that resolves to a bucket leaves nothing on disk to measure. A
figure taken from the filesystem freezes while the account keeps filling,
and on a managed installation that figure is what a customer is shown and
billed against. `by_disk` splits the same sum by where the bytes went,
which is the only way to see what is still sitting locally from before a
cutover. Trashed files are excluded because they hold no bytes -- File's
deleted hook takes them.

Health is what a container cannot show from outside. A queue worker dying
is invisible to anything watching the process: it is still up, and zips
quietly stop building while mail stops going out. Same for a deploy whose
migrations failed -- the application answers every request and is a schema
behind. An unreachable queue reports null rather than zero, because an
unreachable Redis is not an empty queue and reading the second as the
first is how a dead worker looks healthy.

The two-factor enforcement setting is echoed back the way EnforceTwoFactor
reads it, fallback included: reporting a stricter rule than the middleware
actually applies would be worse than reporting none.

And ResolvingInstallationStatus, so a package can report what core cannot
know. The managed storage backend and the version of the package providing
it live in cloud-modules, which this repository must not reference, and a
platform that writes eight environment variables only ever knows what it
asked for. Those came apart once: a bucket provisioned, a token minted,
every variable correct, and an image whose copy of the package predated
the module that reads them. Files went to local disk with the
configuration sitting perfectly right beside them.

Two shapes are cast to objects deliberately. An empty PHP array encodes as
[], so an installation with no packages -- or holding no files -- would
answer a map-shaped field with a list, and a reader unmarshalling it
breaks on the day it happens to be empty rather than the day it is
written. There is a test for each.

Requested by the ProjectSend Cloud control plane, whose storage figure
stops growing the moment a tenant's uploads start reaching the bucket.
 2026-08-28 01:32:25 -03:00
Ignacio Nelson 046be36861 Merge pull request #1710 from denkfabrik-li/fix/folder-delete-file-authority 
FoldersController::destroy() authorized delete on the folder and nothing else, while FolderService::delete() soft-deletes every file in the subtree and File's deleted hook takes the bytes off disk. So a staff member refused a file one route over could destroy it by deleting the folder around it -- permission and library boundary both unasked.

MyFoldersController::destroy() already draws this line for the client half of the same cascade, and says why: owning the folder is not authority over content someone else put in it. This is the staff half of that sentence.

Verified before merging: the four bug tests fail on main and pass here, and the SQL predicate was read line by line against FilePolicy::delete -- it is a faithful negation, including the null-uploader case and the short-circuit for an unscoped viewer holding both delete permissions. Membership of the check is one COUNT, not a policy call per file. Suite at 2099, PHPStan clean.

Behaviour change, deliberately accepted: a folder delete that used to succeed now refuses, naming how many files are in the way. The likely case is somebody who owns a folder another account uploaded into. The alternative is irreversible loss of files the same person is refused individually.

Not taken: deleting what the actor may and keeping the rest. Half a tree is worse than either answer. Naming the blocking files would be friendlier than counting them and is worth doing later -- the list has to hide any file the viewer cannot see, which is its own small design question.

Reported and fixed by @denkfabrik-li.
 2026-08-28 01:20:57 -03:00
Ignacio Nelson 4a35c25894 Merge pull request #1717 from denkfabrik-li/fix/deleted-client-comment-context 
file_comments.client_context_id is cascadeOnDelete, but users are soft-deleted, so the cascade never fires: the column goes on pointing at a row that is still there while the relation resolves to null. resolveClientContext() branched on the relation, so "this is Alice's conversation" read as "this has no conversation" -- and a null context on a clients comment is the branch every client on the file reads. A staff reply into a departed client's private thread became a circular, and canAssignClient() was skipped on the way.

That is the invariant docs/feature-comments.md calls the rule everything hangs off: a clients comment carrying client_context_id = C is never returned to any non-staff viewer other than C, because one customer learning another exists is worse than leaking a comment's text.

Verified before merging: both new tests are red on main and green here, and the three that must not move stay green either way. Suite at 2093, PHPStan clean.

The second half is the same root cause through the other column. authorName() read a deleted client's comment as "Anonymous", which is what a visitor's comment looks like -- and a visitor's comment is governed by different rules, so the two must not be able to look the same. Whether the author is a visitor is now decided by author_id alone, the question isFromGuest() already asks.

Accepted consequence: a soft-deleted client's name is visible on their old comments during the erasure grace period, where it previously read as Anonymous. It goes for good when erasure removes the row.

Reported and fixed by @denkfabrik-li.
 2026-08-28 01:14:48 -03:00
Ignacio Nelson 58497ef776 Merge pull request #1716 from denkfabrik-li/fix/sole-administrator-self-deletion 
ProfileController::destroy() validated the current password and soft-deleted, without asking guardLastAdministrator() -- the rule the other four doors ask, at the one door where the account being removed is certainly signed in. The sole administrator could empty their own installation, and EnsureSetupIsComplete, which asks exists() and so skips trashed rows, then handed the first-run setup form to whoever loaded the page next. That form creates an active System Administrator, unauthenticated.

Verified before merging: on main the sole administrator's self-deletion succeeds and setup reopens; both new tests are red there and green here. Suite at 2088, PHPStan clean.

Two locks, because one of these questions is asked at five doors and the other at one. The guard closes the door. And "has this installation been set up" stops meaning "does it have a working administrator right now" -- a trashed staff row is still evidence that setup happened, counted now in both the middleware and SetupController::setupIsComplete(), which have to agree or the result is a redirect loop or an open form.

Worth recording: erasure force-deletes a self-deleted account after its grace period, so the second lock would expire on its own. It does not matter because the first lock stops the installation reaching that state, but a future change to either should know the other is not permanent.

An installation that has already lost its last administrator now finds setup shut. That is the point: recovery is php artisan projectsend:admin, which is also how every unattended container installs itself.

Reported and fixed by @denkfabrik-li.
 2026-08-28 01:12:14 -03:00
Ignacio Nelson d751314196 Merge pull request #1715 from denkfabrik-li/fix/zip-duplicate-entries 
The job walked the loose file ids and then every selected folder's subtree, adding whatever each pass found. A selection reaching the same file both ways got it twice: two copies of the same bytes, a total_size inflated by the repeat -- which is what the size cap is checked against -- and a file limited to a single download handed over in three copies while the log recorded one, because delivery logs per contained file and DownloadAllowance counts those records.

Verified before merging: the three new tests fail on main and pass here. Suite at 2082, PHPStan clean.

Two halves, because one fix does not cover both shapes. The added-ids list becomes a map keyed by id and the folder pass skips what is already in, before the per-file re-checks, so a duplicate does not spend an allowance twice either. And a folder sitting inside another selected folder is dropped before either is walked, which also settles which path the surviving entry keeps rather than leaving it to row order.

One measured cost, accepted: the pruning compares every selected folder with every other. The pathological case -- ten thousand sibling folders, the selection cap -- benchmarks at around twenty seconds of CPU, in a background worker, on a selection that would take far longer to compress. A sort-by-path-length version would be cheaper if it ever matters.

Reported and fixed by @denkfabrik-li.
 2026-08-28 01:06:43 -03:00
Ignacio Nelson 00d118559d Merge pull request #1714 from denkfabrik-li/fix/group-edit-library-scope 
Every group route asked StaffLibraryScope whether this viewer may act on this group except the two that read it. So a client-scoped staff member could open the edit screen of a group they cannot change, read its membership with addresses, and get the whole client roster in available_clients besides. The API twin returned the same membership.

Verified before merging: the three new tests fail on main and pass here. Two things checked beyond the report -- group membership is edited through separate, already-guarded routes, so narrowing the displayed list cannot remove anybody on save; and scramble:export regenerates byte-identical, as claimed. Suite at 2078, PHPStan clean.

The fix has two halves because one guard does not cover both shapes. Reading the group now asks the same reach question the write half asks. And both lists narrow through StaffLibraryScope::clients(), because a group nobody has shared anything with reaches nowhere, stays open to everybody, and can still hold a stranger's client.

Unscoped viewers are unaffected: clients() returns the whole roster for them and allowsGroupChange() is true by construction.

Reported and fixed by @denkfabrik-li.
 2026-08-28 01:03:23 -03:00
Ignacio Nelson abaca20261 Merge pull request #1713 from denkfabrik-li/fix/api-self-deactivation-boolean 
The  validation rule accepts 0 and "0" as well as false and does not cast, so a strict comparison against the validated array let two of the three spellings past the self-deactivation guard -- and the model's own boolean cast then stored exactly the value the guard had just decided was not a deactivation.

Reproduced on main before merging: {"active": false} is refused, {"active": 0} and {"active": "0"} both return 200 and switch the account off. Green on the branch, suite at 2074, PHPStan clean.

The fix reads the flag once with Request::boolean() and gives that same value to the guard and to the write -- the rule RolesController::guardScopeRemoval already documents for the same reason. Validation is unchanged, so the accepted inputs are the same; one of them just stops meaning two different things on its way through the method.

Follow-up for the release: this is a caller-visible change (200 to 422) and wants a line in api-changelog.md.

Reported and fixed by @denkfabrik-li.
 2026-08-28 01:00:55 -03:00
Ignacio Nelson b16d780ebe Merge pull request #1712 from denkfabrik-li/fix/storage-durability-dashboard-assertion 
The test named for carrying the durability verdict to the system widget asserted only has('system'), and system is an unconditional key of the render array -- the controller's own comment beside storage_durability says as much. So the assertion could not fail.

Confirmed here by deleting the line that supplies the verdict: the new assertion fails with "Property [system.storage_durability] does not exist", where the old one stayed green.

Test-only, no application code.

Reported and fixed by @denkfabrik-li.
 2026-08-28 00:55:45 -03:00
Ignacio Nelson 602c7bed94 Merge pull request #1708 from denkfabrik-li/fix/confirm-password-under-enforcement 
EnforceTwoFactor exempts by route name, and only the GET half of the confirm-password screen had one -- Route::named() answers false for a null name, so the submission was never exempt. Enrolling requires password confirmation, so with enforcement on nobody could enrol at all: the form rendered, its POST was redirected to two-factor.show, auth.password_confirmed_at was never written, and every account on the installation was left with logout as its only working route. Including the administrator who turned the setting on.

Reproduced on main before merging: POST /confirm-password redirects to /settings/two-factor and the session flag stays unset. The widened pattern was checked against the route table -- password.confirm* reaches password.confirm and the newly named password.confirm.store and nothing else; password.reset, password.store and the rest are not under that prefix. Exempting the submission grants nothing further, since every other route stays bounced and store() still validates the password.

Reported and fixed by @denkfabrik-li.
 2026-08-28 00:24:36 -03:00
Ignacio Nelson 76f79d53a0 Merge pull request #1711 from denkfabrik-li/fix/update-tests-clear-compiled 
Ten tests ran the real projectsend:update, which runs clear-compiled, which deletes bootstrap/cache/packages.php and services.php -- one copy for the whole checkout, shared by all eight workers of a parallel run. A worker booting in the window between that delete and its own rebuild reads an empty package manifest, registers no package service providers, and dies rendering the next page with "Target [Inertia\Ssr\Gateway] is not instantiable", in a file that has nothing to do with updates.

Verified here rather than taken on trust: a probe running the real update inside a test on main deletes the manifests, exactly as described. The branch is green at 2066 with PHPStan clean, and touches no application code.

The file already owned a double and explained why the artisan call is a seam; this extends it to the whole file and adds a test asserting the compiled caches survive.

Reported and fixed by @denkfabrik-li.
 2026-08-28 00:19:04 -03:00
ignacionelson 3f81dd5eab Merge pull request #1709 from denkfabrik-li/fix/seat-cap-approval-doors 
Two doors onto the client seat cap did not ask it. Both update()
methods -- the edit screen and PATCH /api/v1/clients/{id} -- clear
account_requested when a pending client is activated, under a comment
saying that counts as approval, and approval is the moment a seat is
spent. So a managed installation sitting at its cap kept taking clients
on for as long as registrations arrived, and self-registration is open
to strangers, so the supply of pending rows is not the operator's to
control.

Verified rather than taken on trust: the two new door tests were run
against the unguarded controllers and fail there, and every place in
app/ that clears the flag was enumerated to check no third door was
missed. There is none -- the other six already ask, and a conversion
refuses a pending account outright rather than approving it sideways.

The guard sits inside the approval branch, so an installation at its cap
can still rename a client it already holds. That is pinned by a test of
its own.

Conflicted with tonight's seat work in SeatAllowanceTest, which had
added an import beside the one this adds. Resolved by keeping both;
suite green at 2065 and PHPStan clean after resolution.

Reported and fixed by @denkfabrik-li.
 2026-08-27 23:30:33 -03:00
Ignacio Nelson 1cefdee610 Merge pull request #1707 from denkfabrik-li/fix/tests-workflow-single-concurrency 
The tests workflow has not parsed since c05927c1 added a second top-level `concurrency:` key four lines below the one that was already there. YAML refuses a duplicate key, so GitHub created a run and scheduled no jobs -- verified here with symfony/yaml ("Duplicate key concurrency detected at line 66") and against the run list: every run since is zero-job, including the commit v2.2.0 is tagged at and all five pushed tonight.

The linter workflow carries one block and kept running, which is why the tree read as checked when the suite had not run at all.

Reported and fixed by @denkfabrik-li.
 2026-08-27 23:29:34 -03:00
ignacionelson f2e7820f5c Say that the seat counts now have a reader outside this application 
The docblock argued for one definition by describing a control plane
showing "2 of 3 seats used" next to an application refusing the fourth,
and the two disagreeing. That was written as a thing to avoid. As of
today it is a screen: the hosted fleet console reads these numbers per
tenant out of projectsend:status --json.

Which makes two rules here load-bearing somewhere nobody editing this
file would think to look -- a deactivated staff account still holds a
seat, a client awaiting approval does not. Changing either changes what
a support person is told before it changes what a customer hits, and
the note is here so that is a decision rather than a surprise.
 2026-08-27 23:25:17 -03:00
ignacionelson a92feed3ad Correct the fifth stale Community-only comment, in QuickStart 
The quick-start list gates its "Add the rest of your team" step on
Capability::UsersManage, which is right and unchanged: it is the seam an
edition difference would travel through. The comment above it still gave
the old reason -- that a managed installation has no staff accounts of
its own to hand out -- which the capability opening on both editions
made false. The step has appeared on a managed installation's list since
623ad68, and GettingStartedTest already says so.

Found by sweeping every repo for the same claim after four others turned
up: core, both module packages, the migration tool, the customer portal
and the private docs. The remaining ones are in the portal's own
planning documents, which are its to correct.
 2026-08-27 23:13:43 -03:00
ignacionelson 73d93495c9 Report the last staff sign-in in projectsend:status 
A platform can see that an installation is running. It cannot see
whether anybody is still using it, and the difference is what separates
a customer from an abandoned free instance holding a database.

So the status probe gains one field:

    "activity": { "last_staff_login_at": "2026-08-24T21:13:32+00:00" }

Null means no staff account has ever signed in, and the key is emitted
either way. That is the whole care in this change: "they said never" and
"we got no answer" have to stay distinguishable, because collapsing them
is how a broken probe reads as a dormant fleet.

Only interactive sign-ins count. Laravel's Login event does not fire for
token authentication, so an integration polling every hour cannot make
an empty installation look busy -- which matters when the reading is
used to decide something.

Derived from the activity log rather than denormalised onto users. A
column would cost a migration, a listener change and a backfill to save
one indexed MAX() over a table with a handful of rows on exactly the
installations anybody asks this about. Nothing prunes the log, and
erasure anonymises entries rather than removing them -- actor_type
survives on purpose -- so the answer does not change when the person who
gave it is forgotten.

Requested by the ProjectSend Cloud control plane, which has no other way
to learn the date. Recorded in docs/api-todo.md as deliberately a
command rather than an endpoint, for the reason the command exists at
all: it observes, it does not accept instructions.
 2026-08-27 22:58:47 -03:00
ignacionelson 2eb23dbc07 Stop four comments saying user management is Community-only 
It stopped being true in 623ad68, when users.manage opened on both
editions. The code moved and these did not, which is the worst kind of
comment: confidently wrong, and about the very rule a reader comes to
them to learn.

PlatformManaged claimed the tenant's own /users screens stay closed,
directly contradicting the UsersManage comment eleven lines above it.
routes/web.php said the same about the group it gates. The API
controller's docblock opened with "**Community only.**", and the
conversion screen's said a managed installation creates staff accounts
elsewhere.

Each now says what is actually true, and says the division the change
turned on: a platform sells the seats, the tenant decides who sits in
them. What limits a managed plan is the seat cap, not a shut door -- so
the API answers 422 at the limit rather than 403, which is a different
sentence to whoever is reading it.
 2026-08-27 22:11:21 -03:00
ignacionelson 13b56186f4 Say the seat limit before the form, not after it 
On a managed installation with its staff seats full, /users/create opened
as though there were room. You typed a name, an address and a password
you had to invent, pressed Save, and the plan limit came back as a
validation error under the email field -- which reads as a complaint
about the address rather than a fact about the plan.

A full installation is an ordinary state on a plan sold by the seat, so
it is now stated up front. The list carries the seat position, the
button goes dead once the last seat is taken and says why, and the
create screen turns away anyone who reaches it by link or bookmark. The
guard in store() is untouched: that is still the rule, this is only the
door.

The refusal is worded once, in SeatAllowance, and the screen is handed
that sentence rather than writing its own -- two wordings of one limit
is how somebody ends up believing there are two limits. `full` is
derived there too, from the same comparison the guard refuses on, so a
screen cannot disagree with it about the edge (used > limit, after an
operator lowers a limit) and offer a button for a form that cannot be
submitted.

Clients get the same treatment: the cap exists there too, and reached it
the same way. Self-hosted installations have no limit, so they are shown
nothing about one.
 2026-08-27 21:02:54 -03:00
denkfabrik-li e272f19045 Keep a private reply private after the client is deleted 
file_comments.client_context_id is cascadeOnDelete, but users are
soft-deleted, so the cascade never fires: the column keeps pointing at a
row that is still there while the Eloquent relation resolves to null.
resolveClientContext branched on the relation, and a null context on a
Clients comment is the branch every client on the file reads -- so a
staff reply into one client's private thread became a circular to all of
them, with the canAssignClient check skipped on the way.

VisibleCommentScope says so in its own docblock: "A Clients comment
carrying client_context_id = C is never returned to any non-staff viewer
other than C ... A Clients comment with a null context is a staff message
to everyone on the file, and every client with access reads it."

Measured on main, with one file shared with two clients and the first of
them deleted after commenting:

  column client_context_id      3
  relation clientContext        null
  POST reply into her thread    201, stored with client_context_id null
  read by the other client      yes

Ask the column, and refuse when the account behind it is gone. There is
nobody left to answer, and the one outcome that must not follow from a
filled column is the broadcast, so this throws rather than falling
through to it.

authorName() had the same root cause from the other column: its docblock
claimed author_id cascades so there is no deleted author, and a deleted
client's comment was going out as "Anonymous" -- which is what a guest
comment looks like, and a guest comment is read by different rules. Guest
is now decided by author_id alone, the same question isFromGuest() asks,
and a trashed author is read with withTrashed(). Nothing comes back only
once the grace-period erasure has removed the row for real.

That read costs one query per comment whose author is trashed. Measured
on a ten-comment thread: 11 queries before, 21 after, against 20 for the
same thread with every author alive. Left as a lazy read rather than
eager-loading with withTrashed() at every call site, because the callers
would each have to remember it and the cost only applies to comments
whose author is gone.

Five tests, two measured red against the unfixed code (2 failed / 3
passed) -- one per column. The three that stay green either way are the
branches that must not move: a staff message with no context still
reaches everybody, a reply into a live client's thread still lands in
that thread alone, and a genuine guest comment is still anonymous.

Full suite passes (2053 passed / 2 skipped), PHPStan level 8 clean.
 2026-08-28 01:44:25 +02:00
denkfabrik-li 28e18497b5 Refuse the last administrator deleting themselves, and keep setup shut 
ProfileController::destroy() validates current_password and soft-deletes.
It never asks StaffAccounts::guardLastAdministrator(), and every other
door does: Staff update(), guardDeletable(), and both directions of the
role conversion. This is the one door where the account being removed is
certainly signed in.

An installation with a single administrator therefore had a button that
emptied it. Measured on main:

  DELETE /settings/profile   302, the account is gone
  live staff rows            0    (the row is trashed, not removed)
  anonymous GET /            302 -> /setup
  anonymous POST /setup      a new active System Administrator

EnsureSetupIsComplete asks ->exists(), which excludes trashed rows, and
routes/web.php registers GET and POST setup with no auth and no guest
middleware -- correctly, since a fresh installation has nobody to
authenticate. SetupController::store() re-checks the same condition, so
both halves agreed with each other and both were wrong once the last
staff row was trashed.

Two locks, because one of them is asked at five doors and the other at
one.

First: destroy() now asks guardLastAdministrator(), the same call with
the same message as everywhere else. An administrator with a colleague
still goes, a non-administrator staff member still goes, and a client
still closes their own account.

Second: "has this installation been set up" is not the same question as
"does it have a working administrator right now", and only the first one
belongs in EnsureSetupIsComplete. A trashed staff row is still evidence
that setup happened, so it now counts -- in the middleware and in
SetupController::setupIsComplete(), which have to agree or the result is
either a redirect loop or an open form.

That second lock holds even if a future door forgets the first one.
Measured with the guard bypassed entirely and the row trashed directly:
GET / answers with the login screen and POST /setup creates nothing.

Worth stating plainly: an installation that has already lost its last
administrator will now find setup shut rather than open. That is the
point -- the recovery path for it is `php artisan projectsend:admin`,
which is also how every unattended container installs itself, not a form
that anybody on the internet can reach.

Six tests, two measured red against the unfixed code (2 failed / 4
passed) -- one per lock. The other four are the boundaries: a colleague
present, a staff member who is not an administrator, a client, and a
genuinely fresh installation that must still reach setup.

Two existing tests needed saying more clearly rather than changing:
ProfileUpdateTest's deletion cases now create a second administrator, so
that what they assert is self-deletion and not this new refusal; and
GettingStartedTest's "fresh installation" cases forceDelete rather than
delete, because a soft-deleted staff row is no longer a fresh
installation -- which is the whole of the second lock.

Full suite passes (2054 passed / 2 skipped), PHPStan level 8 clean.
 2026-08-28 01:35:41 +02:00
denkfabrik-li b44c6bf098 Add a file to a zip once, however many ways the selection reaches it 
BuildZipDownloadJob walks the loose file ids and then every selected
folder's subtree, and adds whatever each pass finds. A selection can
reach the same file from more than one of them, and nothing noticed:

  file_ids [f], folder_ids [Reports]
    -> ['report.pdf', 'Reports/report.pdf']

  file_ids [f], folder_ids [Reports, Reports/Q1]
    -> three entries, file_count 3, total_size three times the file

Two copies of the same bytes in one archive, and total_size is what the
size cap is checked against, so a selection could also be refused for a
weight it does not have.

The one that costs more than bandwidth is delivery. It logs one
FileDownloaded per contained file, and DownloadAllowance counts those
records -- so a file limited to a single download left in three copies
while the log recorded one. Measured: three entries, one record.

Two causes, so two halves.

`$added` is now keyed by id instead of being appended to a list, and the
folder pass skips a file already in the archive. A lookup rather than a
scan because the selection cap is 10000 sources. The loose pass runs
first, so a file picked both ways sits under its loose name; either
answer is defensible, but it has to be the same one every run.

And a selected folder inside another selected folder is dropped before
either is walked. Zipping both would reach every file in the inner one
twice, and which path the surviving entry ended up under would be decided
by the order the rows came back in. Keeping the outer folder keeps the
fuller path -- Reports/Q1/report.pdf rather than Q1/report.pdf.

Containment is decided on the materialized path, so it is one comparison
per pair with no queries: a folder's path starts with an ancestor's
subtreePathPrefix(), and both end in '/', so /5/ cannot match /50/.

Not changed: the per-file re-checks inside the folder pass. Visibility
and the download allowance are still re-derived per file, and the skip
happens before them, so a duplicate never spends an allowance twice
either. Nor the selection endpoint -- a caller may send whatever
selection they like, and the job is where it is resolved.

Four tests. Three measured red against the unfixed job (3 failed / 32
passed): the loose-plus-folder case, the nested-folder case, and the
three-way case asserted through delivery rather than through the archive.
The fourth -- two selected folders that merely share a name are both
zipped -- is green either way and guards the pruning against being about
names rather than containment.

Full suite passes (2052 passed / 2 skipped), PHPStan level 8 clean.
 2026-08-28 01:27:26 +02:00
denkfabrik-li eade690f73 Hold the group edit screen to the same library boundary as the rest 
Every other group route asks StaffLibraryScope whether this viewer may
act on this group. GroupsController::update() and ::destroy() do, and so
do their API twins -- all four with abort_unless(allowsGroupChange, 404).
The two that read do not: edit() and Api\GroupsController::show() had no
boundary at all.

What they hand over is the membership, name and email per member, plus
the whole client roster of the installation as available_clients. So a
client-scoped staff member could open a group whose contents they cannot
see, read off every client on the installation, and only be refused when
they pressed save.

Two halves, because the leak has two shapes:

- The group itself. Reading it now asks the same reach question the write
  half asks, one step earlier, with the same 404 -- a group that reaches
  past the viewer's library is not theirs to open either.
- The lists inside it. Both narrow through StaffLibraryScope::clients(),
  the listing half of the rule this screen's buttons are already guarded
  with: allowsGroupMembership refuses removing a member outside the
  roster, and refuses adding a client outside it. Naming them anyway,
  with their address, is the mistake ClientsController made before
  clients() existed -- that method's own docblock says so.

The reach guard alone would not have been enough. A group nobody has
shared anything with reaches nowhere, so it stays open to everybody --
and it can still hold a stranger's client. That case is why the lists
narrow separately, and there is a test for it.

members_count is left whole on purpose: a size is not an identity, and it
is the same number the group listing already reports.

GroupResource's docblock claimed members are safe to expose because "the
group edit screen already shows [them] to anyone holding edit_groups".
That was a claim about a screen, and it stopped being true the moment the
screen narrowed. Reworded to say what now holds it up, and where.

Not changed: the group listing. It reports names and member counts, not
identities, and every button on it is guarded. Nor Api\GroupsController::
index(), for the same reason. Nor the API document -- scramble:export is
byte-identical, because GET /groups/{group} already documented a 404.

Four tests. Three measured red against the unguarded controllers (3
failed / 21 passed): the group cannot be opened at all, the edit screen
stops naming strangers, and the API twin narrows what it hands back. The
fourth -- an unscoped viewer keeps the whole roster and every member -- is
green either way and guards against the fix over-refusing.

Full suite passes (2052 passed / 2 skipped), PHPStan level 8 clean.
 2026-08-28 01:19:36 +02:00
denkfabrik-li 3e15237f90 Refuse self-deactivation over the API however the boolean is written 
Api\UsersController::update() compares the validated value strictly:

    if ($user->is($actor) && ($validated['active'] ?? true) === false) {

The `boolean` rule accepts 0 and "0" as well as false, and it does not
cast. `0 === false` is false, so the refusal never fires -- and the
model's own `boolean` cast then stores as false exactly the value the
guard had just decided was not a deactivation.

Measured against main, with a second administrator present so that
guardLastAdministrator is not what answers:

    {"active": false}  -> 422, still active
    {"active": 0}      -> 200, active is now false
    {"active": "0"}    -> 200, active is now false

The method's own docblock says it is "Refused with a 422 if the change
would leave the installation with no active administrator, or if you
would be deactivating yourself", and the web screen does refuse. This is
the API half of that sentence.

RolesController::guardScopeRemoval documents the rule this breaks, in the
same words: callers resolve the flag with Request::boolean() and hand the
same value to the guard and to the write, deliberately, because reading
the validated array and comparing it strictly "would let a request
through here that the model's `boolean` cast then stores as false anyway
-- the guard and the write disagreeing about one value is exactly the
shape this guard exists to prevent".

So read it once, with Request::boolean(), and give that one value to both.

Not changed: the validation rule. It stays `boolean`, so the accepted
inputs are the same as before -- what changes is that one of them stops
meaning two different things on its way through. Nor anything about
deactivating somebody else: all three forms still work, and there are
tests saying so.

Six cases from two datasets. Two measured red against the unfixed
controller (2 failed / 4 passed): 0 and "0" on yourself. `false` was
already refused, and the three "somebody else" cases are green either way
-- they guard against the fix over-refusing, not against the bug.

Full suite passes (2054 passed / 2 skipped), PHPStan level 8 clean.
 2026-08-28 01:06:02 +02:00
denkfabrik-li 9cc469b111 Make the storage durability dashboard test assert the verdict 
The test named for carrying the verdict to the system widget only
asserted that the 'system' key exists. It is an unconditional key of the
Inertia::render array and is allowed to be null, and Inertia's has() is a
key check, so the assertion held whether or not the verdict was in there.
Deleting 'storage_durability' from DashboardController::systemInfo() left
the file green.

Substitute the class the way the rest of the file already does and assert
the payload, as InstallationKindTest does for install_kind next door.
 2026-08-28 00:36:32 +02:00
denkfabrik-li 4469648d82 Stop the update tests emptying bootstrap/cache for every other worker 
`UpdateWelcomeTest > staff who may not read system information are not
interrupted` fails on a parallel run roughly one time in six, with

    BindingResolutionException: Target [Inertia\Ssr\Gateway] is not
    instantiable

in a file that has nothing to do with updates. Run alone it is green
every time. The cause is not in that file.

`clear-compiled` deletes bootstrap/cache/packages.php and
bootstrap/cache/services.php. There is one of each for the whole
checkout, and `pest --parallel` gives eight worker processes the same
one. Instrumented over three full runs, the real command ran 12 times per
run -- 11 from UpdateCommandTest, 1 from StaleCodeNoticeTest -- and the
other workers observed the package manifest missing at boot 46 times.

What that costs is in PackageManifest::getManifest():

    if (! is_file($this->manifestPath)) {
        $this->build();
    }

    return $this->manifest = is_file($this->manifestPath) ?
        $this->files->getRequire($this->manifestPath) : [];

A worker that loses the second is_file() to another worker's unlink gets
`[]`: no discovered packages, so no package service providers, so
Inertia's is never registered and `Inertia\Ssr\Gateway` is never bound.
The next page it renders dies in the compiled root view, where
`@inertia` resolves that interface. Any test in any file, whichever one
happened to be booting.

Both halves measured. Building the manifest with inertia-laravel in
`dont-discover` reproduces the reported failure exactly -- same test,
same exception, same frame (`app('Inertia\Ssr\Gateway')` from the
compiled app.blade.php). And 12 real `clear-compiled` calls per run is
the count above.

UpdateCommandTest already owns a double for this, and says why in its own
docblock: the artisan call is a seam. Nine of its tests and one in
StaleCodeNoticeTest simply do not use it. None of them asserts that a
command ran -- they assert EnsureSystemRoles, the settings writes, the
activity log and the welcome marker, and the double touches none of
those. So the seam now covers the file, through a beforeEach rather than
per test, because the next test added here should not have to know any of
this.

The double moves to tests/Support and its helper to tests/Helpers.php,
for the reason that file documents: Pest hands whole files to workers, so
a class declared in one test file does not exist for another.

Not changed: UpdateInstallation. `clear-compiled` belongs in a real
update. Also not changed: giving each worker its own bootstrap/cache
through APP_PACKAGES_CACHE and friends. That would make the destruction
cheap rather than remove it, and nothing in the suite needs those
commands to run at all.

One new test, on the files rather than on the recorded call list -- a
future double that forgot to intercept one command would still satisfy a
call-list assertion. Counter-checked: with the beforeEach removed it goes
red on both manifests being gone (1 failed / 22 passed).

Eight consecutive parallel runs green after the change; the manifests'
mtimes are untouched by a full run, where before they were rewritten
every time. Full suite passes (2049 passed / 2 skipped). PHPStan level 8
clean -- it analyses `app` only, so it does not cover this change.

Pre-existing and left alone: pint reports `ordered_imports` on
UpdateCommandTest.php. Its import block is misordered on main too.
 2026-08-28 00:32:57 +02:00
denkfabrik-li 26205082c2 Stop a folder deleting the files inside it that its owner may not delete 
FoldersController::destroy() authorizes `delete` on the folder and nothing
else. FolderService::delete() then soft-deletes every file in the subtree,
and File::booted()'s `deleted` hook takes the bytes off disk. There is no
restore.

FilePolicy::delete asks two questions the folder route never reaches:
`delete_others_files` for somebody else's upload, and
StaffLibraryScope::allowsFile on top of it. Measured with a role holding
create_own_folders, delete_files, upload and edit_files -- the shape the
Client Manager system role already has, minus delete_others_files:

  DELETE /files/{someone-elses}   403, the file is still there
  DELETE /folders/{their-folder}  302, the file and its bytes are gone

MyFoldersController::destroy already refuses the client half of this exact
cascade, and says why: "Owning the folder is not authority over content
someone else put in it... Refuse rather than silently destroy them." This
is the staff half of the same sentence.

Counted rather than asked per file. A folder can hold thousands, Gate
resolves a fresh policy for every check, and a per-row policy check on a
listing is the cost 0a8b609e went to some trouble to remove. Both halves
of FilePolicy::delete are expressible in SQL: the permission half is
constant for the viewer, and the library half is the query
StaffLibraryScope already memoises per request. Somebody holding both
delete permissions with no library scope short-circuits before the query
runs at all, so the common case pays nothing.

Not changed, deliberately:

- The service. FolderService::delete stays dumb. Its other caller applies
  the client rule ("files you did not upload"), which is a different
  predicate, and putting both in one place is the drift this codebase
  keeps refactoring away from.
- The client half. MyFoldersController is already correct.
- Nothing partial. A blocked folder is left whole rather than emptied of
  what the actor may delete -- half a tree is worse than either answer.

Worth saying plainly: this is a behaviour change. A folder delete that
used to succeed now refuses, and somebody will notice. The alternative is
irreversible loss of files the same person is refused one route over.

Six tests. Four measured red against the unguarded controller (4 failed /
2 passed), one per half of the predicate: the permission half, its
message, a nested file, and the library half -- that last one with both
delete permissions held, so only StaffLibraryScope can refuse. The two
that stay green either way are the other side of the question -- that a
folder holding only your own files still goes, and that an administrator
holding both permissions is unaffected. They guard against the fix
over-refusing, not against the bug.

Full suite passes (2054 passed / 2 skipped), PHPStan level 8 clean.

The new string is English only, per CONTRIBUTING.md -- translations are
their own pass.
 2026-08-28 00:32:33 +02:00
denkfabrik-li ab6e9eecf3 Ask the seat cap where a pending client is approved through edit() 
SeatAllowance says a cap is only a cap if every door asks, and has a test
per door for that reason. Two doors do not ask.

The moment a seat is spent is the moment `account_requested` is cleared.
Five places do that. approve(), both store()s and ClientProvisioning ask
guardClient(); AccountConversion asks it through guardToClient(). The two
update()s -- web and API -- clear the flag with no guard at all, under a
comment that names exactly what they are doing:

    // Activating a pending account through the edit screen counts as
    // approval and clears the request flag.

Measured with clients: 0, one pending registration:

  POST /account-requests/{id}/approve       refused, flag still set
  PATCH /clients/{id}          active=true  approved, clientUsed() 0 -> 1
  PATCH /api/v1/clients/{id}   active=true  approved, clientUsed() 0 -> 1

A managed installation at its cap therefore keeps taking clients on, from
the edit screen or a PATCH, for as long as registrations keep arriving --
and self-registration is open to strangers, so the supply is not the
operator's to control.

Inside the branch, not above it. Above it, an installation sitting at its
cap could not rename a client it already holds, which would trade one
wrong refusal for another. There is a test pinning that.

The field is `active` rather than the default `email`: on this screen the
administrator is toggling `active`, and an error under the email field
would point at the wrong thing. approve() has no form of its own, so it
keeps the default.

Three tests, per door as the file's other eight are. The two door tests
were measured red against the unguarded controllers (2 failed / 18
passed). The third -- that editing an existing client still works at the
cap -- is green either way: it guards against the fix being written a
line too high, not against the bug.

Full suite passes (2051 passed / 2 skipped), PHPStan level 8 clean.

One thing worth knowing that this branch does not touch: on a parallel
run, `UpdateWelcomeTest > staff who may not read...` fails roughly one run
in six on untouched main, with `BindingResolutionException: Target
[Inertia\Ssr\Gateway] is not instantiable`. Measured over 24 baseline runs
before this change existed. It is not this fix, and it is not in scope
here, but it will start being visible as soon as the workflow parses
again.
 2026-08-28 00:19:05 +02:00
denkfabrik-li 1dc274e896 Let an enforced user reach the far side of the confirm-password screen 
EnforceTwoFactor exempts by route name, and only the GET half of
confirm-password has one. routes/auth.php:95 names the form
`password.confirm`; :98 registers its submission with no name at all, and
Route::named() answers false for a null name.

So the loop the exemption exists to prevent is still there, one step
further along. With Setting::TwoFactorEnforcement set to staff, clients
or all, an un-enrolled account walks:

  GET   /dashboard                  -> two-factor.show
  GET   /system/settings/security   -> two-factor.show
  PATCH /system/settings/security   -> two-factor.show
  POST  /settings/two-factor        -> /confirm-password   (RequirePassword)
  GET   /confirm-password           -> 200, the form renders
  POST  /confirm-password           -> two-factor.show     <- not exempt

`auth.password_confirmed_at` is never written, so enrolling can never
start, and every route that is not on the exemption list stays shut --
including Settings -> Security, the one screen that could turn
enforcement back off. Logout is the only door left; recovery is CLI or
database access. It takes one administrator turning the setting on to
reach it, and it reaches every account on the installation at once,
including their own.

The fix is the name. `password.confirm*` then covers both halves of one
screen, matching `two-factor.*` in the same expression; the namespace
belongs entirely to a flow enrolment already depends on being reachable,
and the route table has nothing else under it -- `password.confirm` (GET)
and `password.confirm.store` (POST) are the two it reaches.

Exempting the submission grants nothing further. store() validates the
password, writes a session flag and redirects; the redirect it issues
enters this middleware like any other request, so Settings -> Security is
still answered with two-factor.show after confirming. What changes is
that enrolment can now be started.

Two tests, both measured red against the unfixed middleware: the password
confirmation sticks, and enrolment can be started afterwards (the secret
is written and the screen reports `pending`).

Also named the redirect the existing test settles for. `->assertRedirect()`
with no target passes on this middleware bouncing the request back to
two-factor.show, which is the shape that file exists to refuse. It is a
clarification rather than a guard -- that assertion is green either way,
since the redirect it sees comes from RequirePassword.

Full suite passes (2050 passed / 2 skipped), PHPStan level 8 clean.
 2026-08-27 23:53:53 +02:00
denkfabrik-li 7045da7450 Leave the test workflow one concurrency block, so it parses again 
c05927c1 added a `concurrency:` block on the premise that the suite never
got one. It already had one, four lines above -- the hunk header of that
diff reads `@@ -50,6 +50,23 @@ concurrency:`, which is the existing block
it was appended below.

A YAML mapping cannot carry the same key twice, so the file has not
loaded since. GitHub still creates a run and then schedules nothing:

  553f5fd2  (last green)  run 33036453748  jobs=1  ci -> success
  d58e4830  (main)        run 33114046849  jobs=0  failure

Every run since has that shape, and the run list names it in passing:
those runs appear as `.github/workflows/tests.yml` where the green ones
appear as `tests`, because the `name:` key sits inside the file that did
not parse. `linter` is unaffected -- it carries one block -- which is why
351da21e shows a green linter beside a failed tests run, and the tree
reads as half-checked rather than unchecked.

Reproduced with a parser rather than inferred from the job count:

  before -> THREW: Duplicate key "concurrency" detected at line 66.
  after  -> parsed ok, top-level keys: name,on,concurrency,jobs

Kept the second block, verbatim, because it is the one c05927c1 meant to
end up with and its comment carries the reasoning -- including the
tradeoff that an intermediate commit on `main` can end up with no run of
its own. The two group keys are interchangeable: `github.workflow` is
constant within a workflow, so `tests-${{ github.workflow }}-${{ github.ref }}`
and `tests-${{ github.ref }}` produce the same grouping. Worth knowing
that lint.yml still uses the first shape, if you would rather the two
files read alike.

No test. The failure is loud on the next push, and a test that parses a
workflow file would be a second place to keep the same rule.
 2026-08-27 23:53:37 +02:00
ignacionelson d58e48301f Move the seat number to the end of the sentence 
It read "limited to 1 staff accounts" -- the number sat directly in front
of a countable noun, which is the message a free-tier customer meets the
first time they try to add anybody.

Adding plural forms would fix English and not much else. Polish, Czech and
Russian inflect the noun by the number in front of it, on a three-way split
that a two-form string cannot express, so ':count kont' cannot be right for
every value however many variants it carries. Ending the sentence on the
number means no language has to agree with it -- the same shape the other
counted strings here already use.

Both strings rewritten in all sixteen locales rather than left to the next
translation pass, since the old key would otherwise go missing and block a
build. Checked at 1 and at 25 in English, Spanish, German, Polish and
Russian.
 2026-08-27 17:35:10 -03:00
ignacionelson c49811f3c0 List the issues a release closed 
The summary reads well and says nothing a reader can chase. The numbers and
titles are the way back to the original report, so they go at the end where
they are available without being in the way -- summary at the top for
whoever is deciding whether to upgrade, paper trail at the bottom for
whoever is looking for their own bug.

Generated from the closed-since date rather than hand-picked, and titled
'closed since' rather than 'fixed in' so no per-issue judgement is needed
about how each one was resolved.
 2026-08-27 16:50:11 -03:00
ignacionelson 351da21e8d Stop the text half of an email printing its link twice in brackets 
Laravel's notification view writes the subcopy URL as [$url]($url).
The HTML half parses that into an anchor; the text half parses nothing,
so it arrives as literal brackets around a duplicated address. With the
button line above it the URL appeared three times in one message.

It reads as broken, and it reads broken in a specific direction: a long
opaque token, the recipient's address in the query string, and a
duplicated link in brackets is the shape of a phishing template. On a
password reset, which is often the first mail an installation ever sends
somebody, from a domain with no reputation yet.

Fixed the way every other component in that message already handles the
same split -- one name, two files, Laravel picks per half. Which meant
publishing the framework's view for a one-line change, so there is a note
in it saying to re-copy on upgrade.

Seen in a real reset mail, not in a test.
 2026-08-27 15:29:25 -03:00
ignacionelson c172d0d645 Cut 2.2.0 down to the list and the notes 
The detail underneath was 400 lines of two-and-three-sentence entries.
Written to be complete, and complete is not the same as read: the list at
the top already says what changed, and the long version mostly restated it
at length for somebody who had stopped reading.

The credits do not go with it. Most of the boundary work in this release
came from outside, and dropping the names to save space would be taking
somebody's contribution off the record to tidy a file. One line at the end
instead of twenty inline.

TRUSTED_PROXIES said 'see the fix below' and there is no longer a below.
 2026-08-27 14:54:24 -03:00
302 changed files with 21737 additions and 1488 deletions
Expand all files Collapse all files
.env.example
+14
View File
@@ -4,8 +4,22 @@ PROJECTSEND_EDITION=community
# Emergency off switch for the CAPTCHA on public forms, for an operator who # Emergency off switch for the CAPTCHA on public forms, for an operator who
# has a shell but no working login. Everything else about the feature is # has a shell but no working login. Everything else about the feature is
# configured at /system/settings/captcha. # configured at /system/settings/captcha.
#
# Only "true" or "1" switches it off. Anything else -- including "no",
# "off", and a misspelling -- leaves the CAPTCHA on, deliberately: a flag
# that takes a protection away should not do so because a value was typed
# wrong.
# PROJECTSEND_CAPTCHA_DISABLED=true # PROJECTSEND_CAPTCHA_DISABLED=true
# How downloads leave the server. Left unset (or "auto"), ProjectSend hands
# files to nginx when it is running behind nginx, and streams them through
# PHP on anything else -- which works everywhere but holds a PHP worker for
# the whole of each download. Set "xsendfile" for Apache with mod_xsendfile
# (or LiteSpeed) once XSendFilePath allows storage/app/files, "nginx" when
# an nginx proxy in front is the one serving /protected-files/, or "php" to
# stream deliberately. The dashboard's System panel shows which is in use.
# PROJECTSEND_FILE_DELIVERY=auto
# Optional: uid/gid the app/web containers' internal user runs as, so the # Optional: uid/gid the app/web containers' internal user runs as, so the
# bind-mounted repo needs no permission fixes. Defaults to 1000; override # bind-mounted repo needs no permission fixes. Defaults to 1000; override
# if your host user's `id -u`/`id -g` differ. # if your host user's `id -u`/`id -g` differ.
.github/workflows/tests.yml
-6
View File
@@ -44,12 +44,6 @@ on:
- 'docker/production/dockerhub-overview.md' - 'docker/production/dockerhub-overview.md'
- '.github/screenshots/**' - '.github/screenshots/**'
# A second push supersedes the first: there is no value in finishing a run
# for a commit nobody will look at again.
concurrency:
group: tests-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
# A second push supersedes the first — the later run covers a superset of # A second push supersedes the first — the later run covers a superset of
# what the earlier one was checking, so finishing both buys nothing and # what the earlier one was checking, so finishing both buys nothing and
# costs a runner. # costs a runner.
.gitignore
+4
View File
@@ -39,6 +39,7 @@ yarn-error.log
/database/seeders/DevDataSeeder.php /database/seeders/DevDataSeeder.php
/docs/*.md /docs/*.md
!/docs/api-guide.md !/docs/api-guide.md
!/docs/api-modules.md
!/docs/email-oauth.md !/docs/email-oauth.md
!/docs/api-zapier.md !/docs/api-zapier.md
@@ -46,3 +47,6 @@ yarn-error.log
# mkcert certificates and the nginx config that terminates HTTPS on the # mkcert certificates and the nginx config that terminates HTTPS on the
# dev `web` container. Machine-specific, and one of them is a private key. # dev `web` container. Machine-specific, and one of them is a private key.
/docker/web/local/ /docker/web/local/
# Written into an artifact by build-release.sh, never into a checkout.
/config/build.php
CHANGELOG.md
+375 -395
View File
@@ -6,12 +6,363 @@ Versions follow [SemVer](https://semver.org/): the middle number moves when ther
the last one when there are only fixes, and the first one when an upgrade needs more from you than the last one when there are only fixes, and the first one when an upgrade needs more from you than
dropping in the new files and running the migrations. dropping in the new files and running the migrations.
Anything under **Upgrade notes** is something you have to do, not something we did. Anything under **⚠️ Important — do these yourself** is something you have to do, not something
we did. It sits at the top of a release for that reason. Older entries call the same section
**Upgrade notes**.
## Unreleased ## 2.4.1 — 11 September 2026
This section collects changes as they land; the release process turns it into a numbered entry when ### ⚠️ Important — do these yourself
a version is cut.
Everything else in this release happens on its own. These do not: each one leaves something working
differently from how you expect until you act on it. Nothing here stops the upgrade or the
installation from starting.
- **If you set `PROJECTSEND_CAPTCHA_DISABLED`, check what you set it to.** Only `true` or `1`
switches the CAPTCHA off now. Anything else — including `no`, `off`, `yes` and a misspelling —
used to be read as "yes, disabled" and is now read as "leave it on". If you meant it off, write
`true`.
- **If a staff role uploads into public folders, give it "Upload to public folders".** That
permission was not being asked of staff, and now is. Roles holding "Upload public files" are
unaffected, and ordinary uploads need nothing new.
- **If you use Microsoft sign-in, add the `xms_edov` optional claim to your app registration.** In
the Entra portal: your app registration → Token configuration → Add optional claim → ID →
`xms_edov`. Until you do, Microsoft sign-in keeps working and keeps creating new accounts, but it
will no longer attach itself to an account that already exists.
**Added**
- **Your logo now appears on the sign-in screen.** Requested by
[@Zodiac1978](https://github.com/Zodiac1978) in
[#1777](https://github.com/projectsend/projectsend/issues/1777).
- **An installation on AWS can authenticate as its own IAM role instead of storing an access key.**
- **Clients can now see how often their own files were downloaded, and when.**
**Fixed**
- **A lookalike domain can no longer hand somebody else's account to an OIDC sign-in.** Reported by
[@choewonwoo1817](https://github.com/choewonwoo1817).
- **Changing your own email address now asks for your password.** Reported by
[@Noorkhalel](https://github.com/Noorkhalel).
- **Microsoft sign-in now checks that the person owns the address they presented.** Reported by
[@archnexus707](https://github.com/archnexus707).
- **Two people filling in the first-run setup screen at the same moment can no longer both become
administrators.** Reported by [@ry2811](https://github.com/ry2811).
- **Uploading into a public folder now needs a permission that says so.** Reported by
[@skeletonsec](https://github.com/skeletonsec).
- **Moving a file into a public folder now needs that same permission.** Reported by
[@skeletonsec](https://github.com/skeletonsec).
- **A staff member limited to some clients can no longer see or change other people's groups.**
Reported by [@Drescargot](https://github.com/Drescargot).
- **Deleting a client can no longer hand their files to a client you do not manage.** Reported by
[@skeletonsec](https://github.com/skeletonsec).
- **Erasing a staff account no longer hands their files to a client.**
- **An interrupted upload can no longer park unlimited bytes on the server.** Reported by
[@ry2811](https://github.com/ry2811).
- **The password reset screen no longer says whether an email address has an account here.**
- **An expired password reset link now says so before asking for a new password.**
- **A Docker upgrade no longer fails when external storage is already configured.**
[#1770](https://github.com/projectsend/projectsend/issues/1770).
- **A public gallery no longer renders the same thumbnail several times at once.**
- **`PROJECTSEND_CAPTCHA_DISABLED` no longer reads a "no" as a "yes".**
### Issues closed since 2.4.0
The summary above is what changed. This is the paper trail, for anyone who wants to read the
original report.
- [#1768](https://github.com/projectsend/projectsend/issues/1768) — Search in file not restricted in directory
- [#1773](https://github.com/projectsend/projectsend/issues/1773) — Feature Request : Support AWS IAM roles / default credential provider chain for S3 storage
- [#1774](https://github.com/projectsend/projectsend/issues/1774) — HTTP Error by upload on R2098
- [#1778](https://github.com/projectsend/projectsend/issues/1778) — [Documentation] Error 500 on install
## 2.4.0 — 8 September 2026
Clients can now look after the files they uploaded, and this release closes three ways somebody
could see a little more than they should.
**New**
- **Clients can edit and delete the files they uploaded**, with the name, description, expiry,
categories, download limit and public flag each behind the permission that already governs it.
A file shared *with* a client is still not theirs to touch.
- **A switch to stop this installation fetching the project news**, on Settings → General. On by
default; off means the request is never made.
**Closed holes in who can see what**
- A staff member limited to their assigned clients could read other clients' names, and their IDs,
out of file details and the uploader filter. Reported by
[@Noorkhalel](https://github.com/Noorkhalel) (GHSA-whmp-p9hv-r7j7).
- Download links to external storage now last a minute instead of an hour. Previews keep the hour.
- Eight advisories in bundled dependencies, including an XSS bypass in the markdown renderer that
builds your email templates.
**Fixed**
- A failed upload keeps its parts, so retrying it works instead of needing the whole file again.
- `projectsend:captcha-off` no longer claims success on an installation whose CAPTCHA keys are
supplied centrally, where it changed nothing.
### Upgrade notes
- **Resuming an interrupted download from external storage more than a minute after it started now
fails.** Start it again from ProjectSend. Local-disk installations and zip bundles are unaffected.
- **If your temporary directory is on a small or separate volume, allow headroom for twice your
largest allowed upload.** Only while a file is being assembled, and nothing needs configuring.
Thanks to [@Noorkhalel](https://github.com/Noorkhalel), [@denkfabrik-li](https://github.com/denkfabrik-li)
and [@mehmedturk](https://github.com/mehmedturk) for reporting and fixing.
### Issues closed since 2.3.0
The summary above is what changed. This is the paper trail, for anyone who wants to read the
original report.
- [#1765](https://github.com/projectsend/projectsend/issues/1765) — Projectsend 2.2.1 thumbnail issue after file upload
- [#1771](https://github.com/projectsend/projectsend/issues/1771) — Permissions granted to the Client role are not applied to client accounts
## 2.3.0 — 1 September 2026
If you run ProjectSend on Apache or LiteSpeed, this is the release to take. It installed fine on
both before. Then every download arrived empty and every thumbnail was broken. That is fixed, and
you do not have to configure anything. Installations on nginx were never affected and nothing
changes for them.
The rest is mostly security work. Most of it is the same kind of thing: a screen or an API endpoint
that showed a little more than the person asking was allowed to see.
**New**
- **Downloads work on any web server.** Your files sit outside the web root, so ProjectSend checks
permission on every download before anything is sent. The fast way to finish is to hand the file
to the web server. Each web server wants that asked for differently, and until now ProjectSend
only knew how to ask nginx. On Apache and LiteSpeed it asked anyway, nothing answered, and the
visitor got an empty file. Now it works out what it is talking to. If it cannot hand the file
over, it sends the file itself, which is slower under load but works everywhere.
- **Apache and LiteSpeed can still have the fast version.** Install `mod_xsendfile` (LiteSpeed
needs no module), point `XSendFilePath` at your storage directory, and set
`PROJECTSEND_FILE_DELIVERY=xsendfile`. See the upgrade notes.
- **The dashboard tells you which way downloads are going out.** If PHP is sending them, there is a
warning next to it and a short explanation of what that costs you and how to change it. This is
the kind of thing that is invisible until the day the site falls over, so it says so up front.
- **Your logo and your watermark, on every installation.** Upload a logo and it replaces ours in
the sidebar and on your public pages. Add a watermark and it goes on the thumbnails and previews
your clients and visitors see. Staff still see the originals, and the watermark is never written
into the stored file, so you can turn it off again.
- **You can find out which build you are running.** Two images can say "2.2.1" and contain
different code. `projectsend:status` now reports the commit it was built from.
- **You will know if the nightly jobs stop running.** When the scheduler dies, nothing looks wrong.
You find out weeks later, when a file you expired is still downloadable. ProjectSend now reports
when its scheduled work last ran and whether any of it failed.
- **You get told when the mailbox stops working**, even when a send noticed the problem before the
scheduled check did.
**Closed holes in who can see what**
- [#1745](https://github.com/projectsend/projectsend/pull/1745) — Gate the comment moderation
surfaces on reading, not just on the library. Permission to moderate comments was letting somebody
read them, which is not the same thing: on the moderation screen and through the API, a role that
could moderate comments but could not open any file was shown every comment in the installation —
the text, staff-only notes, the client each conversation belongs to, and a visitor's IP address —
about files it would be refused on. Approving a comment over the API handed back its body the same
way.
**Who this affected.** Only installations with a custom role built that way. None of the roles
ProjectSend ships is affected: Account Manager, the only one that moderates comments, can read
files as well, and so can a System Administrator. If you did build such a role, it can no longer
moderate — give it one of the file permissions (upload, edit files, or edit other people's files)
and it works again, now seeing only the comments on files it can actually open.
- [#1759](https://github.com/projectsend/projectsend/pull/1759) — Publish the example Docker
quickstart on the loopback address instead of every network interface. The example set
`TRUSTED_PROXIES: "*"`, which tells ProjectSend to believe the client address forwarded by
whoever connects to it. That is right behind a reverse proxy and wrong when anyone can reach the
container directly, because then anyone can claim any address: enough to walk past the login
lockout, every rate limit, and the address written to the download log and to guest comments.
**Who this affected.** Installations started from `compose.example.yaml` or from the Docker Hub
page, where port 8080 was reachable from outside the machine. A published Docker port is not
covered by a host firewall such as `ufw`, so this was often open without anyone intending it.
- [#1760](https://github.com/projectsend/projectsend/pull/1760) — Have the Docker image default to
production. On first boot the image copied its settings from the development template, which sets
`APP_ENV=local` and `APP_DEBUG=true`. Two things followed that you could not see from inside the
application: every server error showed its stack trace — file, line and surrounding source — to
whoever triggered it, signed in or not; and **"reject known-breached passwords" never actually
ran**, while the security settings screen went on reporting it as switched on.
**Who this affected.** Anyone who started the container without setting those two values: a plain
`docker run` with a database address, the Portainer, unRAID and TrueNAS templates, or a Kubernetes
manifest naming only the database and `APP_URL`. Installations using `compose.example.yaml`, which
sets both correctly, were never affected.
- The client portal dashboard lists only files that client can open. The API dashboard's recent
activity is cut the same way.
- Three lists were showing more than the viewer was allowed to see: the reassignment picker, the
account conversion list, and the membership an API member write handed back.
- Mail and storage credentials no longer end up in the boot configuration cache. A settings form
that gets rejected no longer sends the credential back to the browser.
- Connecting a sign-in provider asks for your password again. Every password prompt in front of an
account now has its own rate limit instead of sharing one. A two-factor code is claimed in a
single step, so the same code cannot be used twice.
- An expired file no longer locks a whole group shut for staff assigned to particular clients. A
shared folder's contents count towards what a client can reach. A client is added to the roster
of the staff member who created them.
- Whether something is an API request is decided by the route, not by a header the caller sets.
- The interface font is served from your own installation. Loading a page no longer tells a font
CDN who is reading it.
- A stored filename can no longer push a control character into a response header.
**Fixed**
- The zip progress bar stops polling when you leave the page.
- A zip that fails to build no longer tells the person who asked for it why, in the server's words.
- Previews are written to a temporary file first, so a half-written one is never served. A file's
previews are deleted even when its storage cannot be reached.
- An expiry date no longer moves because somebody else saved the file at the same time. Setting one
through the API means what it means on the web form.
- Updating a client through the API no longer wipes custom fields the request never mentioned.
- The transfers chart lines up with the timezone its data is stored in.
- Creating an account over a deleted one's email address is refused instead of crashing.
- A comment still shows who wrote it after that account is deleted.
- Marking a file as a new version no longer emails people about a file they already had.
- The password reset and confirm-password screens say where the account's password actually lives,
which matters if you use LDAP or a sign-in provider.
- A refused upload names the quota you are actually up against. A bulk edit that is refused says
which permission was missing.
- Uploaded folders get the permissions the storage library actually asks for.
- The public preview log no longer records the same view repeatedly.
- Updating with `update.sh` no longer silently switches off route, event and view caching. The
script wiped the compiled caches while replacing the files, which is also how ProjectSend
recognised that you had cached them in the first place — so it rebuilt nothing, and every update
quietly left the site slower than the install instructions promised.
- Every new screen in this release is translated into all sixteen languages.
**Before you upgrade, read the notes below.**
### Upgrade notes
- **This upgrade adds two indexes to the activity log, and on a big installation that takes
minutes.** It is the slowest part. Nothing goes offline while it runs — the application keeps
answering — but do not expect the migration to finish in seconds.
- **On Apache or LiteSpeed you need to do nothing, but there is something worth doing.** Downloads
will start working on their own. PHP will be sending them, which ties up a worker process for the
whole of each download. That is fine on a quiet site and not fine on a busy one. To move to the
fast path: install `mod_xsendfile` (LiteSpeed needs no module), allow your storage directory with
`XSendFilePath`, then set `PROJECTSEND_FILE_DELIVERY=xsendfile` in `.env`. The dashboard will
confirm the change.
- **If you copied the example Docker file, `http://<your-server-ip>:8080` will stop answering.**
That is the change. Reach the application through your reverse proxy, as `APP_URL` describes. If
your proxy runs on a different machine, publish the port on the interface it arrives from and
replace `TRUSTED_PROXIES: "*"` with that address or subnet — the two settings only make sense
together.
- **Docker: `APP_ENV` and `APP_DEBUG` set inside `storage/.env` no longer take effect.** The image
now sets them itself, and a real environment variable always beats that file. If you had turned
debug on by editing `storage/.env`, pass `-e APP_DEBUG=true` (or `environment:` in compose)
instead. Anything you already set that way keeps working unchanged.
Thanks to [@denkfabrik-li](https://github.com/denkfabrik-li), who wrote all forty-four pull
requests in this release, and to [@prbt2016](https://github.com/prbt2016), who reported the Apache
download failure that started the delivery work.
### Pull requests merged since 2.2.1
The summary above is what changed. This is the paper trail, for anyone who wants to read the
original change. No issues were closed in this cycle — the work arrived as pull requests.
- [#1718](https://github.com/projectsend/projectsend/pull/1718) — Narrow the reassignment picker to what a viewer may see
- [#1719](https://github.com/projectsend/projectsend/pull/1719) — Count a shared folder's contents as reach, not just the folder
- [#1720](https://github.com/projectsend/projectsend/pull/1720) — Stop an expired file locking a group shut for a scoped staff member
- [#1721](https://github.com/projectsend/projectsend/pull/1721) — Scope the API dashboard's recent actions to what the viewer may read
- [#1722](https://github.com/projectsend/projectsend/pull/1722) — Show the portal dashboard the files a client can actually open
- [#1723](https://github.com/projectsend/projectsend/pull/1723) — Stop a client PATCH clearing custom fields it never mentioned
- [#1725](https://github.com/projectsend/projectsend/pull/1725) — Write a rendition through a temporary file, and never serve an empty one
- [#1726](https://github.com/projectsend/projectsend/pull/1726) — Delete a file's renditions even when its own disk cannot be resolved
- [#1727](https://github.com/projectsend/projectsend/pull/1727) — Give an API expiry date the same meaning the web gives it
- [#1728](https://github.com/projectsend/projectsend/pull/1728) — Stop an expiry moving because somebody else saved the file
- [#1729](https://github.com/projectsend/projectsend/pull/1729) — Decide what is an API request from the route, not from the caller's headers
- [#1730](https://github.com/projectsend/projectsend/pull/1730) — Refuse to provision over a deleted account's address instead of crashing
- [#1731](https://github.com/projectsend/projectsend/pull/1731) — Fail a zip build without handing the requester the server's reason
- [#1732](https://github.com/projectsend/projectsend/pull/1732) — Debounce the public preview log the way the signed-in one already is
- [#1734](https://github.com/projectsend/projectsend/pull/1734) — Name the quota a client is actually held to when an upload is refused
- [#1735](https://github.com/projectsend/projectsend/pull/1735) — Stop an editable-once checkbox locking before anybody ticks it
- [#1736](https://github.com/projectsend/projectsend/pull/1736) — Put a client on the roster of the scoped staff member who created them
- [#1737](https://github.com/projectsend/projectsend/pull/1737) — Compare the transfers window against the column's own timezone
- [#1738](https://github.com/projectsend/projectsend/pull/1738) — Claim a TOTP code atomically instead of checking then writing
- [#1739](https://github.com/projectsend/projectsend/pull/1739) — Refresh a mailbox on the schedule under the lock a send would hold
- [#1740](https://github.com/projectsend/projectsend/pull/1740) — Leave the caches update.sh's own update command needs to see
- [#1741](https://github.com/projectsend/projectsend/pull/1741) — Ask about the zips queue on every path that could answer it
- [#1742](https://github.com/projectsend/projectsend/pull/1742) — Set the directory permission Flysystem actually reads
- [#1743](https://github.com/projectsend/projectsend/pull/1743) — Check the read half of the redirect rule at every door, not one
- [#1744](https://github.com/projectsend/projectsend/pull/1744) — Stop a version link telling people about a file they already had
- [#1745](https://github.com/projectsend/projectsend/pull/1745) — Gate the comment moderation surfaces on reading, not just on the library
- [#1746](https://github.com/projectsend/projectsend/pull/1746) — Say what expiry does to a client-scoped staff member's library
- [#1747](https://github.com/projectsend/projectsend/pull/1747) — Say which permission a bulk edit was actually missing
- [#1748](https://github.com/projectsend/projectsend/pull/1748) — Let a password reset know where the account's credentials live
- [#1749](https://github.com/projectsend/projectsend/pull/1749) — A deleted account is still the person who wrote the comment
- [#1750](https://github.com/projectsend/projectsend/pull/1750) — Tell the admins the mailbox is dead, even when a send noticed first
- [#1751](https://github.com/projectsend/projectsend/pull/1751) — Keep the mail and storage credentials out of the boot-config cache
- [#1752](https://github.com/projectsend/projectsend/pull/1752) — Bound the two preference endpoints by their own registries
- [#1753](https://github.com/projectsend/projectsend/pull/1753) — Narrow the conversion list to the clients its own refusal allows
- [#1754](https://github.com/projectsend/projectsend/pull/1754) — Narrow the membership an API member write hands back
- [#1755](https://github.com/projectsend/projectsend/pull/1755) — Give every password check in front of an account its own bucket
- [#1756](https://github.com/projectsend/projectsend/pull/1756) — Make linking a provider re-prove the password
- [#1757](https://github.com/projectsend/projectsend/pull/1757) — Stop a rejected settings form flashing the credential it carried
- [#1758](https://github.com/projectsend/projectsend/pull/1758) — Let the confirm-password screen ask where the password lives
- [#1759](https://github.com/projectsend/projectsend/pull/1759) — Publish the quickstart on loopback, since it trusts any proxy
- [#1760](https://github.com/projectsend/projectsend/pull/1760) — Have the production image default to production
- [#1761](https://github.com/projectsend/projectsend/pull/1761) — Serve the interface font from the installation, not from a font CDN
- [#1762](https://github.com/projectsend/projectsend/pull/1762) — Run the auth and settings screens through the translator
- [#1763](https://github.com/projectsend/projectsend/pull/1763) — Stop the zip poll when its page goes away
- [#1764](https://github.com/projectsend/projectsend/pull/1764) — Honour Laravel's placeholder case convention in t()
## 2.2.1 — 28 August 2026
A security release. Most of it closes ways somebody could reach past a boundary the rest of the
application already enforced — including two that could lock you out of your own installation.
**Merged**
- [#1708](https://github.com/projectsend/projectsend/pull/1708) — Let an enforced user reach the far side of the confirm-password screen
- [#1716](https://github.com/projectsend/projectsend/pull/1716) — Refuse the last administrator deleting themselves, and keep setup shut
- [#1710](https://github.com/projectsend/projectsend/pull/1710) — Stop a folder deleting the files inside it that its owner may not delete
- [#1714](https://github.com/projectsend/projectsend/pull/1714) — Hold the group edit screen to the same library boundary as the rest
- [#1717](https://github.com/projectsend/projectsend/pull/1717) — Keep a private reply private after the client is deleted
- [#1713](https://github.com/projectsend/projectsend/pull/1713) — Refuse self-deactivation over the API however the boolean is written
- [#1709](https://github.com/projectsend/projectsend/pull/1709) — Ask the seat cap where a pending client is approved through edit()
- [#1715](https://github.com/projectsend/projectsend/pull/1715) — Add a file to a zip once, however many ways the selection reaches it
- [#1707](https://github.com/projectsend/projectsend/pull/1707) — Leave the test workflow one concurrency block, so it parses again
- [#1711](https://github.com/projectsend/projectsend/pull/1711) — Stop the update tests emptying bootstrap/cache for every other worker
- [#1712](https://github.com/projectsend/projectsend/pull/1712) — Make the storage durability dashboard test assert the verdict
**Also fixed**
- The plain-text version of an email no longer shows the link twice, wrapped in brackets.
- The message you get when an account would exceed a limit no longer reads "limited to 1 staff
accounts".
### Upgrade notes
- **Nothing to do.** Drop in the new files and run `php artisan migrate` as usual; this release adds
no migrations, no settings and no new environment values.
- **One thing changes behaviour.** If somebody on your team has been deleting a folder as a way of
clearing out files other people uploaded, that now refuses and says how many files are in the way.
It is the same rule the file list has always applied one screen over — the folder was the way
around it, and what it removed was not recoverable.
Thanks to [@denkfabrik-li](https://github.com/denkfabrik-li), who reported, diagnosed and fixed
every one of the above.
### Issues closed since 2.2.0
The summary above is what changed. This is the paper trail, for anyone who wants to read the
original report.
- [#1706](https://github.com/projectsend/projectsend/issues/1706) — V1 migration imports $2a$ bcrypt hashes that cause HTTP 500 on login
## 2.2.0 — 27 August 2026 ## 2.2.0 — 27 August 2026
@@ -77,401 +428,30 @@ installed ProjectSend by hand.
a banner naming the problem and the fix. a banner naming the problem and the fix.
- **If you run behind a reverse proxy, check `TRUSTED_PROXIES`.** It is now read correctly, which it - **If you run behind a reverse proxy, check `TRUSTED_PROXIES`.** It is now read correctly, which it
was not before — see the fix below. Set it in `.env`, and do not run `config:cache`, which stops was not before. Set it in `.env`, and do not run `config:cache`, which stops `.env` being read at
`.env` being read at all. all.
### Added Thanks to [@denkfabrik-li](https://github.com/denkfabrik-li), who found, diagnosed and fixed most
of the boundary work above, and to [@mstewart14](https://github.com/mstewart14),
[@elibrachas](https://github.com/elibrachas), [@mueller7382](https://github.com/mueller7382) and
[@pabloalvarez44](https://github.com/pabloalvarez44) for reports and fixes.
- **Google Cloud Storage as a storage backend.** External storage used to mean S3 and nothing else. ### Issues closed since 2.1.0
The Storage settings screen now asks which provider you are using first, and offers Google Cloud
Storage alongside the S3-compatible option: choose it, paste a service account key with read and
write access to your bucket, and new uploads go there. The key is stored encrypted and never shown
again, and **Test connection** checks it can actually reach the bucket before you switch anything
over — using a probe that works with a least-privilege key, rather than one that needs permission
to read the bucket's own settings. Downloads and previews are handed to the visitor as a
short-lived signed link, exactly as they already were for S3.
Nothing changes for an existing installation. Configurations saved before this release are S3, are The summary above is what changed. This is the paper trail, for anyone who wants to read the
still S3, and are not asked to say so. Files already stored stay where they are — the setting original report.
applies to new uploads, and there is still no migration between backends.
- **A maximum size for zip downloads.** A new Settings → Downloads screen sets the largest selection - [#1627](https://github.com/projectsend/projectsend/issues/1627) — Errors while installing via Docker
anyone can ask for as a single zip — 2 GB out of the box, any figure you like, or 0 for no limit. - [#1648](https://github.com/projectsend/projectsend/issues/1648) — A deleted account's email address can never be used again
Building an archive costs disk space and occupies the background worker for as long as it takes to - [#1661](https://github.com/projectsend/projectsend/issues/1661) — Docker update instructions do not update ProjectSend when using official Compose setup
write, so one person asking for a whole library at once used to hold up every notification email - [#1662](https://github.com/projectsend/projectsend/issues/1662) — Preview files not available on v2.1.0
behind it. Ask for more than the limit and you are told how large your selection is and what the - [#1663](https://github.com/projectsend/projectsend/issues/1663) — Dashboard 500s on shared hosting: container detection trips open_basedir
ceiling is, rather than simply refused; each person can have one archive being prepared at a time, - [#1664](https://github.com/projectsend/projectsend/issues/1664) — INSTALL.md: the nginx-in-front-of-Apache path needs the buffer advice too
for the same reason. - [#1668](https://github.com/projectsend/projectsend/issues/1668) — INSTALL.md: X-Accel downloads fail when nginx and PHP-FPM run as different users
- [#1672](https://github.com/projectsend/projectsend/issues/1672) — Projectsend 2 behind Traefik issues 419 when logging in or hitting an error?
- **ProjectSend tells you if nothing is building your zip downloads.** The change below gives zip - [#1673](https://github.com/projectsend/projectsend/issues/1673) — Projectsend 2: Setting Widget Columns throws error
building its own queue, which a manual install's background worker has to be told about. Miss that - [#1675](https://github.com/projectsend/projectsend/issues/1675) — Success toast shows twice after create/delete redirects
and the failure is silent: email keeps going out, zip downloads simply never finish, and nothing - [#1706](https://github.com/projectsend/projectsend/issues/1706) — V1 migration imports $2a$ bcrypt hashes that cause HTTP 500 on login
in any log says why. Staff who can see system information now get a banner naming the problem and
the one-line fix, so nobody has to work it out from a spinner that never stops.
- **Zip downloads no longer hold up your email.** Preparing a large archive can take a while, and it
used to run on the same queue as everything else — so one big zip could delay every notification
email behind it. Zip building now has a queue of its own, and the Docker images run a second
background worker for it.
**Manual installs:** your background worker has to be told about the new queue, or zips will never
finish and nothing will say why. `update.sh` spots this and offers to fix the worker service for
you, keeping a copy of the old one — so for most people there is nothing to do but say yes. If you
update by hand, or your worker already names its own queues (the updater will say so rather than
edit a deliberate arrangement), add `zips` to its `--queue` list and reload systemd. Docker
installations need no change. See INSTALL.md for the two-worker setup if you would rather keep the
two kinds of work apart.
- **A deleted account's email address can be used again.** Deleting an account keeps its record for
a grace period before erasing it for good, and the address stays reserved until that happens — but
only accounts that deleted *themselves* were ever scheduled for erasure. An account an
administrator deleted sat in that state permanently, and its address could never be reused, with
nothing on screen to explain why. Every deletion now schedules the erasure the same way, whoever
performed it, and the staff screens explain a reserved address rather than saying only that it is
taken: which date it frees up, or which command frees it sooner. Public registration deliberately
keeps the plain "already taken" message, since telling a stranger the address once had an account
here is the disclosure that message exists to avoid.
Accounts deleted before this change keep their old state on purpose — stamping them during an
update would quietly start a countdown to erasure that nobody chose. The console command named in
the new message handles those.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1678](https://github.com/projectsend/projectsend/pull/1678), closing
[#1648](https://github.com/projectsend/projectsend/issues/1648))
- **A staff role limited to its own clients now stays limited.** Several ways around that limit are
closed together, because any one of them made the rest decorative. A role holding the "manage
users" permission could edit its own role and simply switch the limit off; it could hand itself
clients it was never assigned; it could promote any client on the installation to a staff account,
which is the most far-reaching thing that can be done to a client record. Uploading into, or
moving a file into, a folder belonging to somebody else's clients is refused too, as is browsing
the folder pickers past your own tree. None of this was reachable with any role that ships with
ProjectSend — each needed a custom role built on the roles screen — but the combinations are ones
the screen offers, so anyone who built one should update.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1681](https://github.com/projectsend/projectsend/pull/1681),
[#1694](https://github.com/projectsend/projectsend/pull/1694),
[#1697](https://github.com/projectsend/projectsend/pull/1697),
[#1700](https://github.com/projectsend/projectsend/pull/1700) and
[#1702](https://github.com/projectsend/projectsend/pull/1702))
- **A public file's private notes stay private.** The comment thread on a publicly listed file is
meant to show what any visitor sees. It was instead answering signed-in visitors as themselves, so
simply having an account — any account — showed staff-only notes on that file, or the messages
addressed to that file's clients. Being signed in now shows you what a visitor sees, plus your own
comments, unless you were entitled to see the file anyway.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1695](https://github.com/projectsend/projectsend/pull/1695))
- **A client is no longer shown the names of folders they cannot open.** Browsing into a folder in
the client portal listed every subfolder inside it, including ones shared with somebody else.
Opening one was always refused, so what escaped was the name — which can be enough, when folders
are named after the people they belong to.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1690](https://github.com/projectsend/projectsend/pull/1690))
- **The maximum file size now applies to large uploads.** Big files are sent in pieces, and the size
limit was only checked against the size the sender *claimed* before sending anything. Declaring a
tiny upload and then sending gigabytes passed every check. The assembled file is now measured
against the limit before it is accepted.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1682](https://github.com/projectsend/projectsend/pull/1682))
- **A download limit now holds when a zip is collected.** Preparing an archive never spent anybody's
download allowance, and only collecting one did — so an archive prepared while a file was still
available stayed collectable after its limit was spent, and several could be held that way at
once. The limit is now checked at the moment the archive is handed over, which is also the moment
it is spent. Archives also record exactly which files went into them, so the download history
counts what was actually delivered rather than re-guessing it afterwards.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1692](https://github.com/projectsend/projectsend/pull/1692))
- **Public downloads work on installations using external storage.** The public listing's download
link always answered as though the file were on the server's own disk, so on an installation
keeping files in object storage it pointed at a path that had never been written. Its neighbours
on the same page — thumbnails and previews — already handled both. Now it does too.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1693](https://github.com/projectsend/projectsend/pull/1693))
- **A large upload cannot be finished twice at once.** A retry or a double submit arriving while the
first was still assembling could interleave with it, storing bytes that no longer matched the
file's own checksum, or recording the same upload twice. Finishing an upload now takes a lock for
that upload, and a second attempt is turned away rather than joining in.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1686](https://github.com/projectsend/projectsend/pull/1686))
- **Deleting an account either finishes or does nothing.** Removing an account and dealing with the
files it owns were two separate steps with nothing holding them together, so a failure in the
second left the account gone and its files still pointing at it — most easily when the person
chosen to inherit them was deleted in between. Both now happen together or not at all. Relatedly,
a file's stored bytes are now removed once the deletion is committed rather than as it happens, so
a cancelled bulk deletion no longer restores records whose files are already gone.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1688](https://github.com/projectsend/projectsend/pull/1688) and
[#1691](https://github.com/projectsend/projectsend/pull/1691))
- **Creating something with a create-only role no longer ends in an error page.** Roles can grant
permission to create clients, staff accounts, groups or categories without permission to edit
them. Creating one worked, but the page it sent you to afterwards was the edit page, which such a
role may not open — so the record was created and you were shown a permission error, with no way
to tell whether it had worked. You now land back on the create form with the confirmation message.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1684](https://github.com/projectsend/projectsend/pull/1684))
### Fixed
- **Accounts migrated from v1 can sign in again.** On some installations brought over from
ProjectSend Legacy, every migrated person got an error page instead of a login screen — while
anybody whose account was created in v2 signed in perfectly. The cause was the label on the stored
password. Older versions of PHP wrote `$2a$` or `$2b$` where newer ones write `$2y$`; all three are
the same algorithm, but ProjectSend only recognised the last one and gave up before it had even
looked at the password. Upgrading relabels the affected accounts in place. Nothing about anybody's
password changes, so there is no reset mail to send and nothing for you to do — the password they
already had simply starts working again. The migration tool no longer creates the problem in the
first place, from version 1.0.3 onwards.
([#1706](https://github.com/projectsend/projectsend/issues/1706), reported by
[@pabloalvarez44](https://github.com/pabloalvarez44))
- **Sessions no longer break behind a reverse proxy.** Signing in, or submitting the first-run setup
form, could answer with a page-filling error instead — most visibly for anyone running behind
Traefik, Nginx Proxy Manager or Caddy. `TRUSTED_PROXIES` was being read too early in the boot
sequence to be seen at all, so the setting had never had any effect on a web request. Without it
ProjectSend believed every visitor was arriving from the proxy over plain HTTP, built its links and
cookies accordingly, and rejected the form that came back as though it had come from somewhere
else. Docker installations that set the value as an environment variable were unaffected the whole
time; manual installs, where the guide tells you to put it in `.env`, were not — which is why this
looked so inconsistent. **Upgrade note:** if you run behind a proxy, set `TRUSTED_PROXIES` and do
not run `config:cache`, which stops `.env` being read at all. Both are covered in INSTALL.md.
([#1672](https://github.com/projectsend/projectsend/issues/1672), reported by
[@mstewart14](https://github.com/mstewart14); fixed by
[@elibrachas](https://github.com/elibrachas) in
[#1674](https://github.com/projectsend/projectsend/pull/1674))
- **Saving something after your session has expired now takes you to the login page.** Instead of
being told to sign in again, you got an unexplained error — the dashboard's widget settings and
several settings screens were the usual places to meet it. The cause was a detail of how browsers
follow redirects: they repeat the original request at the new address, so "save this" became "save
this to the login page", which the login page has no idea what to do with. It now answers in a way
that sends the browser to read the page rather than repeat the save. The same thing could happen to
an account that was deactivated while someone was working in it, or one being asked to set up
two-factor authentication, and both are fixed with it.
([#1673](https://github.com/projectsend/projectsend/issues/1673), reported by
[@mstewart14](https://github.com/mstewart14); found, diagnosed and fixed by
[@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1680](https://github.com/projectsend/projectsend/pull/1680))
- **An upload that cannot be stored now fails instead of disappearing.** When files are kept in
object storage and the storage backend refuses a write — an expired key, a bucket that has been
renamed or removed, a permission that changed underneath you — the upload used to report success
and record the file anyway. The entry appeared in the file list, and the download it promised was
never going to work, because the bytes had gone nowhere. The upload now stops and says so, and no
file is recorded. Installations keeping files on local disk were never affected.
- **Downloads and thumbnails for installations using external storage.** Two places assumed every
file sat on the server's own disk, which stopped being true the moment S3-compatible storage was
switched on. A share link to a file held in a bucket produced a broken download, and a public
listing could not draw a thumbnail for one at all — while the same file downloaded and previewed
correctly everywhere else, which made it look like the share link or the listing was at fault
rather than where the file lived. Both now read the file from wherever it actually is. Nothing
changes for installations keeping files on local disk, which is most of them.
- **One confirmation message instead of two.** Saving a new client, system user or role showed the
same green "Client created." twice, stacked. So did deleting one. It was only ever cosmetic —
nothing happened twice — but it read as though something had, which is the last thing a
confirmation should do. Saves that stay on the same screen, such as the email settings, were never
affected.
([#1675](https://github.com/projectsend/projectsend/issues/1675), reported and diagnosed by
[@denkfabrik-li](https://github.com/denkfabrik-li))
- **Connecting a provider to an account that already has one.** Signing in with Google, Microsoft or
a custom provider worked, but attaching one to an existing account did not: the **Connect** button
on Settings → Connected accounts appeared to do nothing at all. The button asks the server in the
background, and the server answered by redirecting to the provider — a redirect a browser will not
follow out of a background request to another site. The page sat there with no consent screen and
no error to explain it, so the only reading available was that the button was dead. The server now
tells the browser to go to the provider itself, and the flow starts as it should. Signing in from
the login page was never affected, and neither is it now.
([#1676](https://github.com/projectsend/projectsend/pull/1676), found and fixed by
[@denkfabrik-li](https://github.com/denkfabrik-li))
- **Downloads on a host where the web server is not PHP's user.** A download is not served by PHP:
PHP checks permissions and then hands the web server the path to stream. Where the two run as
different users — cPanel and Plesk commonly arrange it that way — the web server could not open
the file, because uploads are written readable only by the account that wrote them. The rest of
the site gave no sign of it: uploading worked, the library listed everything, and only downloads
failed, in the browser as `ERR_INVALID_RESPONSE`. Setting `FILES_WEB_SERVER_READABLE=true` now
writes uploads so the web server can read them. It is opt-in, and deliberately so — the modes it
uses are readable by every account on the machine, which is the wrong trade on a server where the
web server and PHP are the same user, as they are in the Docker image and on most servers people
set up themselves. The install guide has the full procedure, including the one thing no
application setting can fix: a PHP-FPM pool with a restrictive umask, which caps new directories
no matter what ProjectSend asks for.
([#1668](https://github.com/projectsend/projectsend/issues/1668), reported by
[@denkfabrik-li](https://github.com/denkfabrik-li))
- **An installation that builds its own containers is no longer told to pull.** ProjectSend prints
the update instructions for the way you installed it, and it had two answers where it needed
three: anything running in a container was handed `docker compose pull && docker compose up -d`,
including the Compose stack that builds from a checkout of the repository. There is no image
behind those containers to pull, so both commands ran, reported success and changed nothing — and
the dashboard went on offering the same release. Those installations are now recognised and given
`git pull && docker compose up -d --build` instead, with the two extra steps a checkout needs when
a release moves its dependencies or its frontend.
([#1661](https://github.com/projectsend/projectsend/issues/1661), reported by
[@mueller7382](https://github.com/mueller7382))
- **The dashboard no longer fails on shared hosting.** To decide which update instructions to print,
ProjectSend asks whether it is running inside a container by looking for a file in the root of the
filesystem. On shared hosting PHP is usually confined to your own directory, and looking outside it
is treated as an error rather than as a "no" — so the one page that asks the question, the
dashboard, returned a 500 while every other page worked. It now takes the restriction as the answer
it always was: a server that keeps PHP inside a single directory is not our container image, and
gets the manual update instructions, which is correct for shared hosting anyway. Nothing to change
on your side, and no setting you would have been able to change if there were.
([#1663](https://github.com/projectsend/projectsend/issues/1663), reported by
[@denkfabrik-li](https://github.com/denkfabrik-li))
- **502 Bad Gateway behind a reverse proxy.** Every page carried a `Link:` header listing its
frontend assets, duplicating tags the page already had in its `<head>` — twenty of them on the
login screen, more on a heavier page. nginx buffers a response's headers into a single block that
defaults to 4 KB, so the file list, at over 6 KB of headers, was refused with `upstream sent too
big header` and the proxy answered 502. Which pages went over depended on how many assets they
loaded, so it looked like an intermittent fault: the login screen appeared, and then the
application did not. The duplicate header is gone — the same pages now send under 1.3 KB — and no
browser loses anything, because the tags it actually reads were always in the document. The
install guide gained the proxy buffer settings for anyone on an older version or behind a proxy
holding a tighter default.
([#1664](https://github.com/projectsend/projectsend/issues/1664), reported by
[@denkfabrik-li](https://github.com/denkfabrik-li))
- **`docker logs` now shows the web server's log.** The container runs nginx, PHP-FPM, the queue
worker and the scheduler, and all of them reported to Docker except the one you need when a
request fails: nginx opened the log files named in its own configuration and wrote to them inside
the container, where nothing looks. The effect was that a proxy problem produced no logs on either
side — the reason for every 502 and every 403 existed, in a file nobody knew to open. Both its
access and error logs now go to the container's output, and the Docker guide has a section on
running behind a reverse proxy that says which side a given message points at.
- **A zip download is never offered over an archive that was not written.** Archives are built in the
background, and the writing all happens at the very end — so a source file deleted while the build
waited its turn, or a disk that filled up, produced no archive at all while the download was still
marked ready. Clicking it then failed with an unexplained error. The same went for a selection
whose files had all become unavailable: an archive with nothing in it is not written to disk
either. Both now fail the build and say why. Large archives were affected differently: a build
taking longer than a minute was killed by the queue worker and the download simply spun forever,
waiting for something that had already stopped. Builds now get the time they need, a build the
queue gives up on reports itself as failed, and the partial files an interrupted build leaves
behind are cleaned up rather than sitting on disk unnoticed.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1687](https://github.com/projectsend/projectsend/pull/1687))
- **Comment moderation now stops at the same boundary everything else does.** A staff role can be
limited to its own assigned clients, and everything in the library respects that — listings,
downloads, file details, and the moderation queue itself. Deleting or approving a single comment
did not. Someone with a client-limited role who also held the comment moderation permission could
remove any comment on the installation by its id, including conversations belonging to clients
they were not assigned to, on files they could not open. No role that ships with ProjectSend
combines those two things, so this needed a custom role to reach; if you have built one, it is
worth updating for. The boundary now lives in the rule itself rather than being restated by each
screen, which is how the gap opened in the first place.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1698](https://github.com/projectsend/projectsend/pull/1698))
- **The dashboard's recent activity now respects a limited role's boundary.** A staff role can be
limited to its own assigned clients, and the activity page has always honoured that — showing only
entries about files, folders and clients in that person's scope. The dashboard's Recent activity
widget did not: it listed the eight most recent entries from the whole installation, file names
and all, to someone who would be refused the files themselves. The Client Manager role ships with
the permission this widget needs, so any installation using it was affected. Both screens now
answer the same way. Nothing changes for an administrator or any unrestricted role.
- **Cached previews are no longer mistaken for stray files.** The tool that finds files sitting on
disk with no database record knew to ignore cached thumbnails, but had never been told about the
larger previews added alongside them. So every cached preview was listed as an unclaimed file:
offered for import on the orphan-files screen, and deleted by the daily cleanup once past its
grace period. Importing one also created a file entry pointing at a path the preview cache owns,
which then vanished the next time that cache was cleared. The list of what counts as a generated
copy is now derived from the copies themselves, so a new kind cannot be left off it again.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1683](https://github.com/projectsend/projectsend/pull/1683))
- **Group membership now respects a limited role's boundary.** A staff role can be limited to its
own assigned clients. Adding somebody to a group, or taking them out, checked only that the person
held the "edit groups" permission — not that the group was any of their business. Because joining a
group hands the new member everything shared with it, someone with a limited role could put one of
their own clients into any group on the installation and, through that client, reach files they
had been refused a moment earlier. Approving or denying a membership request was the same write
through a second door, and the requests screen listed every pending request by name and email,
including clients outside the viewer's roster. All of it is now held to the same boundary the rest
of the library uses, and the sidebar count agrees with the screen behind it. No role that ships
with ProjectSend combines the two permissions this needed, so reaching it took a custom role.
Nothing changes for an administrator or any unrestricted role.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1701](https://github.com/projectsend/projectsend/pull/1701))
- **Declining a group membership request now happens once.** Approving a request that had already
been decided was refused; declining one was not, and declining is not a repeatable act. Each
repeat re-dated the decision — which is what the client's waiting period before asking again
counts from — so the same stale request, sent again, could keep somebody out of a group
indefinitely without anyone deciding anything. It also wrote a second entry in the activity log
and sent the client a second "your request was declined" email for one decision. The queue only
ever lists requests still waiting, so nothing on screen offered this. Both actions now behave the
same way.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1705](https://github.com/projectsend/projectsend/pull/1705))
- **The dashboard's expired-files list says whose files it is showing.** For a staff role limited to
its own clients it lists that person's own uploads, since an expired file is already out of reach
of the clients it was shared with. It now says so — "Your expired files", and a line explaining
what is not in the list — rather than presenting a short list as though it were the whole picture.
A warning about what is due to be deleted is worth nothing if it is quietly narrower than it looks.
- **A limited staff role no longer reaches every client record, or every file name on the
dashboard.** Two more places where holding a permission was treated as holding a boundary. The
clients screen listed every client on the installation by name and email, and a role limited to
its own assigned clients could open, rename, or delete any of them — the same through the API.
Separately, the dashboard's largest-files, expired-files and top-clients widgets named files and
clients from across the whole installation, which mattered more because the Client Manager role
that ships with ProjectSend holds the permission those widgets need. Both now use the same rule
the rest of the library already did. Installation-wide totals stay installation-wide: a count
carries no names. Nothing changes for an administrator or any unrestricted role.
- **Notification settings accept only the switches they offer.** Saving your notification
preferences would store a row for any name a request happened to carry, including ones nothing in
ProjectSend can send. Such a row was never read again and could not be seen or removed from the
screen, so the table quietly collected entries nobody could reach. The form now checks what comes
back against the same list it offered, so the two cannot drift apart. Nothing reachable from the
screen changes — it only ever sends back switches it was given.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1689](https://github.com/projectsend/projectsend/pull/1689))
- **A two-factor recovery code is now spent exactly once.** Using a code removed it from your list
by rewriting the whole list, so two sign-in attempts arriving at the same moment could each save
their own copy and put back the code the other had just spent. Nobody could get in who was not
already holding a valid code, but a code you had crossed off a printed sheet — or watched somebody
type — could quietly start working again, which is the one thing recovery codes promise not to do.
The code is now removed from the record as it stands at that moment, under a lock, so a second
attempt cannot undo the first.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1704](https://github.com/projectsend/projectsend/pull/1704))
- **A file can no longer be filed into a folder that has been deleted.** Deleting a folder deletes
everything inside it, so a file that lands in one afterwards sits somewhere that was already
emptied — reachable by link and in search, but missing from the folder listing its uploader would
look in. Uploading or moving a file into a deleted folder now says so instead, and picks up the
case where a folder is deleted while a large upload is still transferring: the finished file lands
at the top level rather than being thrown away, since the transfer had already happened. The
message says the folder no longer exists rather than that the value was invalid.
(found, diagnosed and fixed by [@denkfabrik-li](https://github.com/denkfabrik-li) in
[#1703](https://github.com/projectsend/projectsend/pull/1703))
- **A limited staff role can no longer rename or delete a group it has no part in.** Group
membership was already held to that boundary; the group itself was not, which was the sharper half
— sharing a file with a group is how its members reach that file, so deleting the group takes the
access away from every one of them, including clients outside the person's own list. A role
limited to its own clients can still manage any group that shares nothing beyond what it can
already see, so a group it created, or one holding its own clients, stays fully editable. Nothing
changes for an administrator or any unrestricted role.
## 2.1.0 — 18 August 2026 ## 2.1.0 — 18 August 2026
DOCKER.md
+8 -1
View File
@@ -121,6 +121,13 @@ Without it every visitor appears to come from the proxy. The login rate limiter
your users as one attacker, and the download log records the proxy's address instead of the your users as one attacker, and the download log records the proxy's address instead of the
person's. `compose.example.yaml` already sets this. person's. `compose.example.yaml` already sets this.
`"*"` means "trust whoever connected to me", so it belongs with a published port only the proxy can
reach — which is why `compose.example.yaml` publishes on `127.0.0.1`. If anybody can open the
container's port directly, they are the proxy as far as this setting is concerned, and the
`X-Forwarded-For` they send is the address the rate limiters and the download log will use. Where
the proxy runs on another host, publish on the interface it arrives from and name that address or
subnet here instead of `"*"`.
Leaving it unset does not cause a `502` — that means your proxy could not get a usable response out Leaving it unset does not cause a `502` — that means your proxy could not get a usable response out
of the container at all, which is a different problem with a different fix. It does cause a **419 of the container at all, which is a different problem with a different fix. It does cause a **419
"page expired"**. Without it the application never learns the proxy terminated TLS, so it builds "page expired"**. Without it the application never learns the proxy terminated TLS, so it builds
@@ -177,7 +184,7 @@ is the quickest way to separate "the app is down" from "the proxy cannot reach t
during an outage, from the same machine: during an outage, from the same machine:
```sh ```sh
curl -s -o /dev/null -w '%{http_code}\n' http://<host-ip>:8080/up # straight at the container curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/up # straight at the container
curl -s -o /dev/null -w '%{http_code}\n' https://files.example.com/up curl -s -o /dev/null -w '%{http_code}\n' https://files.example.com/up
``` ```
INSTALL.md
+162 -54
View File
@@ -21,7 +21,7 @@ to create a database — this is not an install you can do over FTP alone.
| **PHP** | 8.4 or newer, both the command-line PHP and PHP-FPM | | **PHP** | 8.4 or newer, both the command-line PHP and PHP-FPM |
| **PHP extensions** | `bcmath` `ctype` `curl` `dom` `fileinfo` `filter` `gd` `iconv` `intl` `json` `ldap` `mbstring` `openssl` `pcntl` `pdo_mysql` `session` `simplexml` `tokenizer` `zip` | | **PHP extensions** | `bcmath` `ctype` `curl` `dom` `fileinfo` `filter` `gd` `iconv` `intl` `json` `ldap` `mbstring` `openssl` `pcntl` `pdo_mysql` `session` `simplexml` `tokenizer` `zip` |
| **Database** | MySQL 8.0 or newer (we test on 8.4 LTS) | | **Database** | MySQL 8.0 or newer (we test on 8.4 LTS) |
| **Web server** | **nginx**, with PHP-FPM — see the note below | | **Web server** | Any, with PHP-FPM. **nginx is strongly recommended** — see the note below |
| **Disk space** | The app itself is small; plan for whatever your users will upload | | **Disk space** | The app itself is small; plan for whatever your users will upload |
A few notes on that list: A few notes on that list:
@@ -29,66 +29,113 @@ A few notes on that list:
- **`ldap` is required even if you never use LDAP.** One of the libraries ProjectSend depends on - **`ldap` is required even if you never use LDAP.** One of the libraries ProjectSend depends on
declares it, so PHP will refuse to start the app without it. On Debian/Ubuntu it is declares it, so PHP will refuse to start the app without it. On Debian/Ubuntu it is
`php8.4-ldap`; on RHEL-family systems, `php-ldap`. `php8.4-ldap`; on RHEL-family systems, `php-ldap`.
- **nginx is not a preference, it is a requirement.** See [Why nginx](#why-nginx) — it is worth - **nginx is recommended, not required.** ProjectSend runs on Apache and LiteSpeed too, and
two minutes of reading before you commit to a server, because Apache cannot be made to work by downloads work on them out of the box. What differs is *how* the bytes are sent: on nginx the
configuring it differently. web server sends them, and everywhere else PHP does, which costs a worker process for the
duration of every download. See [How downloads are sent](#how-downloads-are-sent) before you
commit to a server — it is a capacity decision, not a compatibility one.
- **Redis is optional.** The Docker setup uses it, but a manual install works fine with the - **Redis is optional.** The Docker setup uses it, but a manual install works fine with the
database for sessions, cache and queues. If you already have Redis, see database for sessions, cache and queues. If you already have Redis, see
[Optional extras](#optional-extras) below. [Optional extras](#optional-extras) below.
### Why nginx ### How downloads are sent
Your uploaded files do not live under `public/`. They sit in `storage/app/files/`, outside the web Your uploaded files do not live under `public/`. They sit in `storage/app/files/`, outside the web
root, where no URL can reach them — which is the whole point: a file is only yours to download if root, where no URL can reach them — which is the whole point: a file is only yours to download if
ProjectSend says so, and a file sitting in a guessable public folder has already lost that ProjectSend says so, and a file sitting in a guessable public folder has already lost that
argument. argument.
So every download has to pass through a permission check. The obvious way to do that is to let PHP So every download has to pass through a permission check in PHP first. What happens *after* that
read the file and echo it back to the browser, and that is what most PHP applications do. It works, check passes is the thing this section is about, and ProjectSend can do it two ways.
and it is a bad idea at any real size: a single 5 GB download occupies a PHP process for its entire
duration, so a handful of people downloading at once can exhaust every worker your server has while
the CPU sits idle. Resumable downloads, byte ranges and progress bars all have to be reimplemented
by hand, usually incorrectly.
ProjectSend does the other thing. PHP checks permissions, logs the download, and then answers with **PHP sends the file.** It opens the file and writes it out to the visitor. This works on every
an empty response carrying a header that says *"nginx, please send this file."* nginx streams the web server and needs no configuration, which is why it is what ProjectSend falls back to. The cost
bytes with the same code it uses for any static file — sendfile, byte ranges, resume support, no is that one PHP worker process is occupied for the whole of each download — three minutes for a
PHP process held open — and the visitor never sees the real path. The header is large file on a slow connection is three minutes that worker cannot answer anything else. A
`X-Accel-Redirect`, and the matching `location /protected-files/` block in handful of concurrent large downloads can therefore occupy every worker you have and the site
[step 6](#step-6--point-your-web-server-at-it) is marked `internal`, which is what stops anyone stops responding, with the processor idle and the workers all waiting on network transfers.
from requesting that path directly.
**Apache has no equivalent that ProjectSend can use.** Apache's closest feature, `mod_xsendfile`, **The web server sends the file.** PHP answers with an empty response and a header naming the
reads a differently-named header (`X-Sendfile`) that ProjectSend does not send, and it is not file, and finishes immediately; the web server streams the bytes with the same code it uses for
installed by default anyway. LiteSpeed has its own third spelling. On any of them the application any static file — `sendfile`, byte ranges, resume support, no PHP process held open — and the
installs fine and every page works — you can log in, upload, manage clients, browse the library — visitor never sees the real path. This is what you want on anything busy.
but **every download returns an empty response or a 404**, because nothing is listening for the
instruction PHP just gave. There is no setting to change; the header names simply do not match.
Two ways out, if nginx really is impossible on your hosting: The second option needs a header, and **each web server reads a different one**, which is why
ProjectSend has to know which one it is talking to. It works this out from the server itself and
you can override it.
- Put nginx in front of Apache as a reverse proxy, serving `/protected-files/` itself. This works | Your server | What ProjectSend does | What you need to configure |
but is more moving parts than just using nginx. Give the proxy some header headroom while you are |---|---|---|
there — the same headroom the reference configuration in Step 6 gives PHP-FPM, in the directives a | nginx | `X-Accel-Redirect` | The `location /protected-files/` block in [step 6](#step-6--point-your-web-server-at-it). Detected automatically |
proxy uses instead: | Apache | PHP sends the file, unless you enable `mod_xsendfile` | See below |
| LiteSpeed / OpenLiteSpeed | PHP sends the file, unless you turn on X-Sendfile | See below |
| Anything else | PHP sends the file | Nothing |
```nginx **The dashboard tells you which one is in use.** The System panel has a "Downloads sent by" line,
proxy_buffer_size 32k; with a warning icon and an explanation whenever PHP is doing the sending. You do not have to
proxy_buffers 8 32k; remember to check this file.
proxy_busy_buffers_size 64k;
```
nginx buffers a response's headers into a single block that defaults to one memory page — 4 KB on #### Enabling X-Sendfile on Apache or LiteSpeed
most systems — and answers `502 Bad Gateway` with `upstream sent too big header` when they do not
fit. The page that goes over is not always the same one, so it presents as an intermittent fault Apache needs [`mod_xsendfile`](https://github.com/nmaier/mod_xsendfile) installed and enabled, and
rather than as a misconfiguration. This applies to any proxy in front of ProjectSend, not just a directive allowing it to serve your storage directory:
this one: Nginx Proxy Manager, Traefik and a hand-written nginx vhost all ship the same default.
([#1664](https://github.com/projectsend/projectsend/issues/1664)) ```apache
- Store your files in object storage instead — S3-compatible or Google Cloud Storage (see XSendFile On
[Storing files somewhere other than this server](#storing-files-somewhere-other-than-this-server)). XSendFilePath /home/projectsend/storage/app/files
Files kept there are never on your server's disk, so downloads become a signed, expiring redirect ```
to the storage provider and the web server is not involved at all. This is a genuine, supported
path — just decide it before people start uploading, not after. LiteSpeed and OpenLiteSpeed read the same header without an extra module; enable it in the server
configuration.
Then tell ProjectSend to use it, in `.env`:
```dotenv
PROJECTSEND_FILE_DELIVERY=xsendfile
```
**ProjectSend will not switch this on by itself**, even when it can see the module is loaded,
because it cannot see whether `XSendFilePath` allows the storage directory. Guessing wrong there
produces empty downloads rather than slow ones, and an empty download is a much worse failure than
a slow one — so this stays something you turn on having configured it.
#### Choosing explicitly
`PROJECTSEND_FILE_DELIVERY` accepts:
| Value | Meaning |
|---|---|
| `auto` | The default. nginx if the server says it is nginx, PHP otherwise |
| `nginx` | Always `X-Accel-Redirect`. Use this if nginx is proxying another server |
| `xsendfile` | Always `X-Sendfile`, for Apache with `mod_xsendfile`, or LiteSpeed |
| `php` | Always PHP. Correct and slow, and never wrong |
The one case `auto` gets wrong is **nginx reverse-proxying Apache**: PHP is talking to Apache, so
it picks PHP streaming, and downloads work but do not use the nginx in front. Set
`PROJECTSEND_FILE_DELIVERY=nginx` and make sure the front nginx serves `/protected-files/`. While
you are there, give the proxy some header headroom — the same headroom the reference configuration
in Step 6 gives PHP-FPM, in the directives a proxy uses instead:
```nginx
proxy_buffer_size 32k;
proxy_buffers 8 32k;
proxy_busy_buffers_size 64k;
```
nginx buffers a response's headers into a single block that defaults to one memory page — 4 KB on
most systems — and answers `502 Bad Gateway` with `upstream sent too big header` when they do not
fit. The page that goes over is not always the same one, so it presents as an intermittent fault
rather than as a misconfiguration. This applies to any proxy in front of ProjectSend, not just
this one: Nginx Proxy Manager, Traefik and a hand-written nginx vhost all ship the same default.
([#1664](https://github.com/projectsend/projectsend/issues/1664))
#### Or take your server out of it entirely
Store your files in object storage — S3-compatible or Google Cloud Storage (see
[Storing files somewhere other than this server](#storing-files-somewhere-other-than-this-server)).
Files kept there are never on your server's disk, so downloads become a signed, expiring redirect
to the storage provider and the web server is not involved at all. Decide this before people start
uploading, not after.
--- ---
@@ -216,10 +263,10 @@ FILES_WEB_SERVER_READABLE=true
Uploaded files are written `0600` inside `0700` directories, readable only by the user that wrote Uploaded files are written `0600` inside `0700` directories, readable only by the user that wrote
them. That is deliberate, and on a same-user server it is the safer setting. But a download is not them. That is deliberate, and on a same-user server it is the safer setting. But a download is not
served by PHP: PHP checks permissions and then hands the web server the path with `X-Accel-Redirect` served by PHP on nginx: PHP checks permissions and then hands the web server the path with
(see [Why nginx](#why-nginx)), so the web server has to open a file PHP owns. When it cannot, **the `X-Accel-Redirect` (see [How downloads are sent](#how-downloads-are-sent)), so the web server has
whole site works and only downloads fail** — the browser reports `ERR_INVALID_RESPONSE` and the to open a file PHP owns. When it cannot, **the whole site works and only downloads fail** — the
nginx error log says: browser reports `ERR_INVALID_RESPONSE` and the nginx error log says:
``` ```
open() ".../storage/app/files/..." failed (13: Permission denied) open() ".../storage/app/files/..." failed (13: Permission denied)
@@ -277,8 +324,9 @@ like your logo reachable from the web.
## Step 6 — Point your web server at it ## Step 6 — Point your web server at it
A complete nginx server block. Change `server_name`, and change `/var/www/projectsend` to wherever A complete nginx server block below; [Apache is further down](#if-you-are-using-apache). Change
you unpacked the files (there are **three** places, including one inside `/protected-files/`): `server_name`, and change `/var/www/projectsend` to wherever you unpacked the files (there are
**three** places, including one inside `/protected-files/`):
```nginx ```nginx
server { server {
@@ -327,6 +375,38 @@ server {
} }
``` ```
### If you are using Apache
Two things matter, and both are easy to get wrong:
- **The document root is the `public/` directory**, not the directory you unpacked into. Everything
above `public/` — your `.env`, your uploaded files, the application code — has to stay out of
reach of any URL.
- **`AllowOverride All`, and `mod_rewrite` enabled** (`sudo a2enmod rewrite`). ProjectSend ships a
`public/.htaccess` that sends every address to the front controller. If Apache is told to ignore
it, every page except the home page is a 404.
```apache
<VirtualHost *:80>
ServerName files.example.com
DocumentRoot /var/www/projectsend/public
<Directory /var/www/projectsend/public>
AllowOverride All
Require all granted
</Directory>
ErrorLog ${APACHE_LOG_DIR}/projectsend-error.log
CustomLog ${APACHE_LOG_DIR}/projectsend-access.log combined
</VirtualHost>
```
Downloads work as they are: PHP sends the bytes. If that becomes a capacity problem, `mod_xsendfile`
hands the job to Apache — see [How downloads are sent](#how-downloads-are-sent).
On shared hosting you usually cannot edit any of this, and `public/.htaccess` is all you have. If
the site returns a 500 on every page, see [When something goes wrong](#when-something-goes-wrong).
Then check your PHP settings. Large uploads are sent in 20 MB pieces, so PHP never has to handle a Then check your PHP settings. Large uploads are sent in 20 MB pieces, so PHP never has to handle a
whole 5 GB file at once — but the pieces still need room. In your `php.ini`: whole 5 GB file at once — but the pieces still need room. In your `php.ini`:
@@ -534,6 +614,28 @@ names the exact command to run; do that, then reload.
Look in `storage/logs/` — open the newest file, the real error is at the bottom. Nine times out of ten it is Look in `storage/logs/` — open the newest file, the real error is at the bottom. Nine times out of ten it is
folder permissions (step 4) or a wrong database password (step 3). folder permissions (step 4) or a wrong database password (step 3).
**Every page is a 500, and `storage/logs/` is empty.**
The empty log is the answer, not a dead end: nothing reached PHP, so ProjectSend had nothing to
write. The error is your web server's, and it is in your web server's log — on Apache
`/var/log/apache2/error.log`, or wherever your host puts it. On Apache two causes account for
almost all of these, and both are about `public/.htaccess`:
- **`Options not allowed here`.** The file starts by turning off directory listings and content
negotiation, and your `AllowOverride` does not permit that. Allow it (`AllowOverride All`), or
delete the `Options` line — it is hardening, not a requirement.
- **`Request exceeded the limit of 10 internal redirects`.** Apache cannot work out which directory
the file is serving, so the rule that sends every address to `index.php` rewrites to a path that
does not exist, and tries again. Uncomment the `RewriteBase` line in `public/.htaccess` and set it
to the path ProjectSend is served from — `/` at the domain root, `/projectsend` in a subdirectory.
Reported on IONOS by [@Zodiac1978](https://github.com/Zodiac1978) in
[#1778](https://github.com/projectsend/projectsend/issues/1778).
**If you edit `public/.htaccess`, write down what you changed.** Updating replaces every file the
release ships, that one included, so a change that made your site work will be gone after the next
update and the 500 will come back. If the Apache configuration is yours to edit, put the directives
in a `<Directory>` block in the vhost instead: they do the same job there, and no update can touch
them. On shared hosting, where it is not yours, keep the note and re-apply it.
**"Please provide a valid cache path" or "failed to open stream".** **"Please provide a valid cache path" or "failed to open stream".**
`storage/` or `bootstrap/cache/` is not writable by the web server user. Step 4. `storage/` or `bootstrap/cache/` is not writable by the web server user. Step 4.
@@ -546,9 +648,15 @@ That is correct behaviour until the first administrator exists. Finish step 7. I
created one and it still happens, ProjectSend cannot reach your database — check `storage/logs/`. created one and it still happens, ProjectSend cannot reach your database — check `storage/logs/`.
**Pages load but downloads give a 404, or download a 0-byte file.** **Pages load but downloads give a 404, or download a 0-byte file.**
The `/protected-files/` block is missing from your nginx config, or its `alias` path does not match On nginx, the `/protected-files/` block is missing from your config, or its `alias` path does not
where you installed ProjectSend. It must point at `storage/app/files/` and end with a slash. If you match where you installed ProjectSend. It must point at `storage/app/files/` and end with a slash.
are on Apache or LiteSpeed, no configuration will fix this — see [Why nginx](#why-nginx).
On any server, check the "Downloads sent by" line in the dashboard's System panel against the
server you are actually running. A 0-byte download means ProjectSend sent a header the server did
not act on — most often `PROJECTSEND_FILE_DELIVERY` set to `nginx` or `xsendfile` on a server that
is neither, or set to `xsendfile` without `XSendFilePath` allowing the storage directory. Setting
`PROJECTSEND_FILE_DELIVERY=php` always works and is the quickest way to confirm that is the
problem. See [How downloads are sent](#how-downloads-are-sent).
**Uploads fail partway through.** **Uploads fail partway through.**
`client_max_body_size` in nginx, or `upload_max_filesize` / `post_max_size` in `php.ini`, is `client_max_body_size` in nginx, or `upload_max_filesize` / `post_max_size` in `php.ini`, is
README.md
+5
View File
@@ -23,6 +23,11 @@ page to download it.
No public link passed around by email, no third-party service holding your clients' documents, no No public link passed around by email, no third-party service holding your clients' documents, no
per-seat pricing. It runs on your server, and the files stay there. per-seat pricing. It runs on your server, and the files stay there.
Prefer not to run the server yourself? [ProjectSend Cloud](https://projectsend.cloud) is the
official hosted version of ProjectSend, run by the same team — every subscription funds this free
software. The line between the free core and Cloud, and the commitments that go with it, are set
out in [LICENSING.md](LICENSING.md).
## What it does ## What it does
**For the people you send to** **For the people you send to**
app/Http/Controllers/Auth/ConfirmablePasswordController.php
+11 -6
View File
@@ -3,9 +3,9 @@
namespace App\Http\Controllers\Auth; namespace App\Http\Controllers\Auth;
use App\Http\Controllers\Controller; use App\Http\Controllers\Controller;
use App\Modules\Identity\PasswordVerification;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Illuminate\Validation\ValidationException; use Illuminate\Validation\ValidationException;
use Inertia\Inertia; use Inertia\Inertia;
use Inertia\Response; use Inertia\Response;
@@ -22,16 +22,21 @@ class ConfirmablePasswordController extends Controller
/** /**
* Confirm the user's password. * Confirm the user's password.
*
* Through PasswordVerification, so this asks the same question the
* sign-in form asks: is this the account's password, from wherever
* that account's password lives. Checking only the local hash refused
* every directory-provisioned account the password it actually has --
* their local hash is a Str::password(64) nobody has ever seen -- and
* this screen stands in front of enrolling in two-factor, so those
* accounts could not enrol at all.
*/ */
public function store(Request $request): RedirectResponse public function store(Request $request, PasswordVerification $passwords): RedirectResponse
{ {
$user = $request->user(); $user = $request->user();
assert($user !== null); assert($user !== null);
if (! Auth::guard('web')->validate([ if (! $passwords->verify($user, (string) $request->string('password'))) {
'email' => $user->email,
'password' => $request->password,
])) {
throw ValidationException::withMessages([ throw ValidationException::withMessages([
'password' => __('auth.password'), 'password' => __('auth.password'),
]); ]);
app/Http/Controllers/Auth/NewPasswordController.php
+111 -3
View File
@@ -3,6 +3,8 @@
namespace App\Http\Controllers\Auth; namespace App\Http\Controllers\Auth;
use App\Http\Controllers\Controller; use App\Http\Controllers\Controller;
use App\Modules\Identity\AuthSource;
use App\Modules\Identity\Ldap\LdapAuthenticator;
use Illuminate\Auth\Events\PasswordReset; use Illuminate\Auth\Events\PasswordReset;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request; use Illuminate\Http\Request;
@@ -16,6 +18,10 @@ use Inertia\Response;
class NewPasswordController extends Controller class NewPasswordController extends Controller
{ {
public function __construct(
private readonly LdapAuthenticator $ldap,
) {}
/** /**
* Show the password reset page. * Show the password reset page.
*/ */
@@ -24,9 +30,53 @@ class NewPasswordController extends Controller
return Inertia::render('auth/reset-password', [ return Inertia::render('auth/reset-password', [
'email' => $request->email, 'email' => $request->email,
'token' => $request->route('token'), 'token' => $request->route('token'),
'expired' => $this->linkIsSpent(
(string) $request->string('email'),
(string) $request->route('token'),
),
]); ]);
} }
/**
* Whether this link is one store() is certain to refuse.
*
* The scaffolding renders the form without looking at the token, so an
* expired link asked for a new password, asked for it a second time to
* confirm, and only then answered "this password reset token is
* invalid" — naming a word nobody outside the code knows, after the
* work rather than before it. Reset links last an hour and people open
* them late; that is ordinary, not an error to be scolded for.
*
* store() still validates and remains the rule. This is the screen
* being honest a minute earlier.
*
* **Anything that will not validate reads as expired, whether or not
* the address is one we know.** That is the whole of the rule and it
* exists for one reason: a page answering "expired" for a real address
* and drawing the form for an unknown one tells anybody who types a
* guess whether an account is here — the exact property
* /forgot-password protects by saying "a link will be sent if the
* account exists".
*
* The first version of this method described that oracle in a comment
* and then built it: unknown address returned false and drew the form,
* known address returned true and said expired. Two branches, two
* answers, and the difference *was* the account. Now both answer the
* same, so the page reveals nothing and the message is still right in
* every case somebody real will meet — a mistyped address gets "ask
* for a new link", which is what they should do anyway.
*/
private function linkIsSpent(string $email, string $token): bool
{
$broker = Password::broker();
$user = $email === '' ? null : $broker->getUser(['email' => $email]);
// One answer for "no such account", "wrong token" and "spent
// token", because telling them apart is telling somebody which
// addresses exist here.
return $user === null || ! $broker->tokenExists($user, $token);
}
/** /**
* Handle an incoming new password request. * Handle an incoming new password request.
* *
@@ -46,10 +96,55 @@ class NewPasswordController extends Controller
$status = Password::reset( $status = Password::reset(
$request->only('email', 'password', 'password_confirmation', 'token'), $request->only('email', 'password', 'password_confirmation', 'token'),
function ($user) use ($request) { function ($user) use ($request) {
$user->forceFill([ // A directory account's password lives in the directory and
// the local hash is not consulted at all, which is what
// isDirectoryAccount() means. Writing one here reported
// success and changed nothing anybody could use -- including
// when the directory it points at is gone, which is exactly
// when somebody reaches for a reset.
//
// Refused here rather than where the link is asked for: that
// endpoint answers "A reset link will be sent if the account
// exists" to everybody on purpose, and a refusal there would
// tell a stranger both that an address is an account and how
// it signs in. By this point the caller holds a token that
// was emailed to the address, so the explanation reaches the
// account holder and nobody else.
//
// Throwing before the write also leaves the token unspent:
// PasswordBroker deletes it after the callback returns, so
// the link still works if an administrator converts the
// account in the meantime.
if ($this->ldap->isDirectoryAccount($user)) {
throw ValidationException::withMessages([
'email' => [__('This account signs in through your directory, so its password is not set here. Ask an administrator if you cannot sign in.')],
]);
}
$attributes = [
'password' => Hash::make($request->password), 'password' => Hash::make($request->password),
'remember_token' => Str::random(60), 'remember_token' => Str::random(60),
])->save(); ];
// `social` records that the account came into existence
// without anybody choosing a password, which AuthSource
// states outright -- along with "a social account may later
// set a real password". This is that moment, and nothing
// else in the application writes it: the Connected accounts
// screen reads `auth_source === Local` as
// `has_local_password`, so without this line its refusal
// goes on asking for a password that has just been set.
//
// The two branches of this method are the same rule read
// twice: `social` is where the account came from and the
// hash here is what signs it in, so choosing one settles it;
// `ldap` is the authentication path itself, so nothing
// chosen here settles anything.
if ($user->auth_source === AuthSource::Social) {
$attributes['auth_source'] = AuthSource::Local;
}
$user->forceFill($attributes)->save();
event(new PasswordReset($user)); event(new PasswordReset($user));
} }
@@ -62,8 +157,21 @@ class NewPasswordController extends Controller
return to_route('login')->with('status', __($status)); return to_route('login')->with('status', __($status));
} }
// One sentence for every way this can fail, and deliberately not
// Laravel's own. The scaffolding answers `passwords.user` for an
// address it cannot find and `passwords.token` for a real one whose
// token is dead — two different sentences, which is the same
// account-enumeration oracle the screen above was fixed for,
// reachable through the write instead. `passwords.throttled` is the
// third and the sharpest: the broker throttles per *user*, so an
// address nobody holds can never be throttled, and being told to
// wait is being told the account is there.
//
// Nothing is lost by collapsing them. The action is the same in
// every case — ask for a new link — and /forgot-password already
// refuses to say whether an address has an account.
throw ValidationException::withMessages([ throw ValidationException::withMessages([
'email' => [__($status)], 'email' => [__('This password reset link is no longer valid. Ask for a new one and try again.')],
]); ]);
} }
} }
app/Http/Controllers/Settings/ProfileController.php
+15
View File
@@ -9,6 +9,7 @@ use App\Modules\Audit\ActivityLogger;
use App\Modules\Clients\ClientFieldContext; use App\Modules\Clients\ClientFieldContext;
use App\Modules\Clients\ClientPortalCustomFields; use App\Modules\Clients\ClientPortalCustomFields;
use App\Modules\Identity\Erasure\ErasureSchedule; use App\Modules\Identity\Erasure\ErasureSchedule;
use App\Modules\Identity\StaffAccounts;
use App\Modules\Platform\Localization\TimezoneRegistry; use App\Modules\Platform\Localization\TimezoneRegistry;
use App\Modules\Platform\Settings\Setting; use App\Modules\Platform\Settings\Setting;
use App\Modules\Platform\Settings\Settings; use App\Modules\Platform\Settings\Settings;
@@ -24,6 +25,7 @@ class ProfileController extends Controller
public function __construct( public function __construct(
private readonly ClientPortalCustomFields $customFields, private readonly ClientPortalCustomFields $customFields,
private readonly TimezoneRegistry $timezones, private readonly TimezoneRegistry $timezones,
private readonly StaffAccounts $accounts,
) {} ) {}
/** /**
@@ -104,6 +106,19 @@ class ProfileController extends Controller
$user = $request->user(); $user = $request->user();
assert($user !== null); assert($user !== null);
// The rule every other door into this already asks: Staff update(),
// guardDeletable(), and both role-conversion directions. This one
// did not, and self-deletion is the one door where the account
// being removed is certainly signed in — so the last active
// administrator could take themselves out, leaving no live staff
// row at all. EnsureSetupIsComplete then reopens first-run setup to
// anybody who asks, which is the other half of this and is closed
// below.
$this->accounts->guardLastAdministrator(
$user,
removesAdmin: $this->accounts->isAdministratorRole($user->role_id),
);
Auth::logout(); Auth::logout();
// Self-deletion: soft delete now, permanent GDPR erasure after // Self-deletion: soft delete now, permanent GDPR erasure after
app/Http/Middleware/HandleInertiaRequests.php
+60
View File
@@ -24,7 +24,10 @@ use App\Modules\Platform\Settings\Settings;
use App\Modules\Platform\Updates\LatestReleaseInfo; use App\Modules\Platform\Updates\LatestReleaseInfo;
use App\Modules\Platform\Updates\RunningCodeState; use App\Modules\Platform\Updates\RunningCodeState;
use Illuminate\Foundation\Inspiring; use Illuminate\Foundation\Inspiring;
use App\Modules\Platform\Announcements\Events\ResolvingAnnouncement;
use App\Modules\Platform\Navigation\Events\ResolvingNavigationLinks;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Support\Facades\Event;
use Inertia\Middleware; use Inertia\Middleware;
class HandleInertiaRequests extends Middleware class HandleInertiaRequests extends Middleware
@@ -84,6 +87,19 @@ class HandleInertiaRequests extends Middleware
// ignore this and always show it. // ignore this and always show it.
'attribution' => app(Attribution::class)->visible(), 'attribution' => app(Attribution::class)->visible(),
'capabilities' => $capabilities->enabledKeys(), 'capabilities' => $capabilities->enabledKeys(),
// Sidebar entries a package asked for. Shared rather than
// passed per page because the sidebar is on every page, and
// dispatched unconditionally so that with nothing listening
// the list is empty and the sidebar is exactly what it was.
// See ResolvingNavigationLinks for why core never learns what
// is in it.
'extra_nav_links' => $this->extraNavLinks($request),
// Shared rather than a dashboard prop, because it is shown in
// two places — the band on the dashboard and the icon beside
// the notification bell everywhere else — and "the same
// message" is the requirement. Two props would drift the day
// somebody edited one.
'announcement' => $this->announcement($request),
// Shared rather than passed by each page: the sign-in buttons, // Shared rather than passed by each page: the sign-in buttons,
// the registration form and the Connected accounts nav entry // the registration form and the Connected accounts nav entry
// all need the same list, and a nav entry to a screen with // all need the same list, and a nav entry to a screen with
@@ -301,4 +317,48 @@ class HandleInertiaRequests extends Middleware
/** @var array<string, string> */ /** @var array<string, string> */
return app('translator')->getLoader()->load($locale, '*', '*'); return app('translator')->getLoader()->load($locale, '*', '*');
} }
/**
* @return list<array{title: string, url: string, external: bool, icon: string|null}>
*/
private function extraNavLinks(Request $request): array
{
$user = $request->user();
// Staff only, decided here rather than in each listener: these
// render in the administration area, and a client's portal shows
// their own files and nothing about the installation.
$event = new ResolvingNavigationLinks(isStaff: $user !== null && $user->isStaff());
if (! $event->isStaff) {
return [];
}
Event::dispatch($event);
return $event->links;
}
/**
* @return array{title: string, body: string, action_label: string|null, action_url: string|null, tone: string}|null
*/
private function announcement(Request $request): ?array
{
$user = $request->user();
if ($user === null) {
return null;
}
// Dispatched for clients too, unlike the sidebar links beside it.
// A client is somebody a shared instance may legitimately need to
// address — about their own account, not about the installation —
// and the event refuses anything not aimed at them, so widening
// this does not widen what reaches them.
$event = new ResolvingAnnouncement(isStaff: $user->isStaff());
Event::dispatch($event);
return $event->announcement;
}
} }
app/Http/Requests/Auth/LoginRequest.php
+15 -68
View File
@@ -3,13 +3,13 @@
namespace App\Http\Requests\Auth; namespace App\Http\Requests\Auth;
use App\Models\User; use App\Models\User;
use App\Modules\Identity\Ldap\LdapAuthenticator; use App\Modules\Identity\AccountLookup;
use App\Modules\Identity\Ldap\LdapProvisioner; use App\Modules\Identity\Ldap\LdapProvisioner;
use App\Modules\Identity\PasswordVerification;
use App\Modules\Identity\SignIn; use App\Modules\Identity\SignIn;
use App\Modules\Platform\Captcha\CaptchaForm; use App\Modules\Platform\Captcha\CaptchaForm;
use App\Support\Rules; use App\Support\Rules;
use Illuminate\Auth\Events\Lockout; use Illuminate\Auth\Events\Lockout;
use Illuminate\Auth\SessionGuard;
use Illuminate\Contracts\Validation\ValidationRule; use Illuminate\Contracts\Validation\ValidationRule;
use Illuminate\Foundation\Http\FormRequest; use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Support\Facades\Auth; use Illuminate\Support\Facades\Auth;
@@ -72,7 +72,13 @@ class LoginRequest extends FormRequest
{ {
$this->ensureIsNotRateLimited(); $this->ensureIsNotRateLimited();
$user = User::query()->where('email', $this->string('email'))->first(); // Exact, for the reason SocialAuthenticator is: a collation that
// folds accents would otherwise let somebody typing
// admin@éxample.com be *identified* as admin@example.com. A
// password still gates this one, so it was never the takeover the
// social path was — but identifying the wrong account is the bug,
// and the credential check is a second line rather than the rule.
$user = app(AccountLookup::class)->byEmail((string) $this->string('email'));
// A directory identity with no local account yet. Returns null // A directory identity with no local account yet. Returns null
// unless LDAP is on, auto-provisioning is on, and the bind // unless LDAP is on, auto-provisioning is on, and the bind
@@ -115,10 +121,9 @@ class LoginRequest extends FormRequest
/** /**
* The account whose password checks out, or null. * The account whose password checks out, or null.
* *
* The local hash is tried first and the directory only on failure, so * The rule itself -- local hash first, directory when the credentials
* a login that succeeds locally never generates directory traffic. * live there -- is PasswordVerification's, because this is no longer
* The exception is an account whose credentials are known to live in * the only screen that has to ask it. See that class.
* the directory, where the local hash is a placeholder nobody holds.
*/ */
private function verifyCredentials(?User $user): ?User private function verifyCredentials(?User $user): ?User
{ {
@@ -126,67 +131,9 @@ class LoginRequest extends FormRequest
return null; return null;
} }
$ldap = app(LdapAuthenticator::class); return app(PasswordVerification::class)->verify($user, (string) $this->string('password'))
? $user
if (! $ldap->isDirectoryAccount($user) : null;
&& Auth::validate($this->only('email', 'password'))) {
$this->upgradeHashIfStale($user);
return $user;
}
$identity = $ldap->attempt(
(string) $this->string('email'),
(string) $this->string('password'),
$user,
);
if ($identity === null) {
return null;
}
$ldap->stamp($user, $identity);
return $user;
}
/**
* Re-hash a password stored under weaker settings than this
* installation now uses.
*
* Laravel does this for you inside SessionGuard::attempt(), but this
* form does not use attempt() — it verifies with Auth::validate() and
* hands the account to SignIn, which calls Auth::login(). Neither
* re-hashes, so without this an account keeps whatever cost it was
* created under forever, and raising BCRYPT_ROUNDS would quietly
* apply to new accounts only.
*
* That is not hypothetical: every account the v1 migration carries
* across arrives as `$2y$08$…`, because v1 hashed at cost 8, and
* would otherwise stay four times cheaper to attack than an account
* created here.
*
* **Only ever called on the local branch.** On the directory branch
* the submitted plaintext is the *LDAP* password and the local hash
* is a `Str::password(64)` placeholder nobody holds; writing the
* directory credential into it would mint a second way into the
* account that keeps working after LDAP is switched off.
*/
private function upgradeHashIfStale(User $user): void
{
$guard = Auth::guard('web');
// getProvider() is on SessionGuard rather than on the StatefulGuard
// contract. This guard is a SessionGuard in every configuration this
// application ships; the check is here so a custom driver degrades
// to "no re-hash" instead of a fatal on the login path.
if (! $guard instanceof SessionGuard) {
return;
}
// No-ops unless the hasher says the stored digest needs it, so
// this costs an already-current account nothing.
$guard->getProvider()->rehashPasswordIfRequired($user, $this->only('password'));
} }
/** /**
app/Http/Requests/Settings/ProfileUpdateRequest.php
+62
View File
@@ -5,9 +5,11 @@ namespace App\Http\Requests\Settings;
use App\Models\User; use App\Models\User;
use App\Modules\Clients\ClientFieldContext; use App\Modules\Clients\ClientFieldContext;
use App\Modules\Clients\ClientPortalCustomFields; use App\Modules\Clients\ClientPortalCustomFields;
use App\Modules\Identity\AuthSource;
use App\Support\Rules; use App\Support\Rules;
use Illuminate\Contracts\Validation\ValidationRule; use Illuminate\Contracts\Validation\ValidationRule;
use Illuminate\Foundation\Http\FormRequest; use Illuminate\Foundation\Http\FormRequest;
use Closure;
use Illuminate\Validation\Rule; use Illuminate\Validation\Rule;
class ProfileUpdateRequest extends FormRequest class ProfileUpdateRequest extends FormRequest
@@ -31,6 +33,26 @@ class ProfileUpdateRequest extends FormRequest
Rule::unique(User::class)->ignore($this->user()?->id), Rule::unique(User::class)->ignore($this->user()?->id),
], ],
// Changing this address is a credential change, not a detail:
// it is where a password reset is sent, so whoever can change
// it owns the account from the next reset onwards. A stolen
// session used to be enough (GHSA-f32x-fgmp-q353) — temporary
// access became permanent ownership with one PATCH.
//
// `exclude_if` rather than a flat rule, so the rest of the
// screen keeps saving with nothing extra: a name, a timezone
// or a custom field is not a credential and must not start
// asking for a password. Only a *different* address does.
//
// The same rule destroy() one controller away has always
// asked, for the same reason: both doors lead to owning the
// account.
'current_password' => [
Rule::excludeIf(! $this->changesEmail()),
'required',
'current_password',
],
// Saved with the rest of the profile so the screen keeps one // Saved with the rest of the profile so the screen keeps one
// Save button. `timezone` is fillable, so ProfileController's // Save button. `timezone` is fillable, so ProfileController's
// fill() picks it up with no special handling. // fill() picks it up with no special handling.
@@ -43,6 +65,21 @@ class ProfileUpdateRequest extends FormRequest
]; ];
$user = $this->user(); $user = $this->user();
// An account whose credentials live in a directory or at an
// identity provider holds a local password nobody knows — see
// LdapProvisioner, which stores Str::password(64) exactly so it
// can never be used. Asking such a person to confirm "your current
// password" is a dead end dressed as a form error, and the address
// is not theirs to change here in any case: it is what the
// directory or the provider says it is, and a local edit would
// either be overwritten or break the link.
if ($this->changesEmail() && $user !== null && $user->auth_source !== AuthSource::Local) {
$rules['email'][] = function (string $attribute, mixed $value, Closure $fail): void {
$fail(__('Your email address comes from the directory or identity provider you sign in with, and cannot be changed here.'));
};
}
if ($user?->isClient() === true) { if ($user?->isClient() === true) {
$rules = [ $rules = [
...$rules, ...$rules,
@@ -52,4 +89,29 @@ class ProfileUpdateRequest extends FormRequest
return $rules; return $rules;
} }
/**
* Whether this request asks for an address other than the stored one.
*
* Compared lowercased and trimmed because the `lowercase` rule runs
* beside this one rather than before it: without that, re-saving the
* profile with the address typed in a different case would be read as
* a change and demand a password for nothing.
*/
private function changesEmail(): bool
{
$user = $this->user();
if ($user === null) {
return false;
}
$submitted = $this->input('email');
if (! is_string($submitted)) {
return false;
}
return mb_strtolower(trim($submitted)) !== mb_strtolower(trim((string) $user->email));
}
} }
app/Models/User.php
+10
View File
@@ -161,6 +161,16 @@ class User extends Authenticatable implements HasLocalePreference
// credentials live is a security decision, not an attribute a // credentials live is a security decision, not an attribute a
// form or an API payload may set. Written with forceFill by // form or an API payload may set. Written with forceFill by
// the code that provisions the account. // the code that provisions the account.
//
// Same for 'email_verified_at' below, and it is worth saying
// what absence from $fillable does and does not buy. It stops
// a request smuggling the value in. It does not tell the code
// that meant to set it deliberately that it failed: a key in a
// create() array is dropped in silence, so every path that
// provisions an account had one and lost it — staff accounts,
// client accounts, the setup screen and projectsend:admin, all
// fixed in September 2026. Not fillable only helps when the
// writer knows it has to be deliberate.
'auth_source' => AuthSource::class, 'auth_source' => AuthSource::class,
'ldap_synced_at' => 'datetime', 'ldap_synced_at' => 'datetime',
'active' => 'boolean', 'active' => 'boolean',
app/Modules/Api/ApiUsage.php
+19 -1
View File
@@ -8,6 +8,7 @@ use App\Models\User;
use App\Modules\Api\Auth\ApiTokens; use App\Modules\Api\Auth\ApiTokens;
use App\Modules\Api\Models\ApiRequestLog; use App\Modules\Api\Models\ApiRequestLog;
use App\Modules\Audit\ActivityLog; use App\Modules\Audit\ActivityLog;
use App\Modules\Audit\ActivityLogScope;
use App\Modules\Audit\ActivityOrigin; use App\Modules\Audit\ActivityOrigin;
use Illuminate\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Builder;
use Illuminate\Support\Carbon; use Illuminate\Support\Carbon;
@@ -27,6 +28,7 @@ class ApiUsage
{ {
public function __construct( public function __construct(
private readonly ApiUsageScope $scope, private readonly ApiUsageScope $scope,
private readonly ActivityLogScope $activityLog,
) {} ) {}
/** /**
@@ -145,7 +147,23 @@ class ApiUsage
*/ */
public function recentActions(User $viewer, bool $installWide, int $limit = 15): array public function recentActions(User $viewer, bool $installWide, int $limit = 15): array
{ {
$query = ActivityLog::query()->where('origin', ActivityOrigin::Api); // Narrowed through ActivityLogScope, exactly as the activity page,
// the download history and the dashboard widget are.
// `view_actions_log` decides whether the install-wide view opens at
// all, but it is not the whole answer for a client-scoped viewer: a
// row carries the subject's name, so an unscoped feed reads out file
// and client names to somebody who gets a 403 on the files
// themselves. The Client Manager role ships with the permission, so
// this is the default configuration, not an exotic one.
//
// Applied on both sides of the branch rather than only in the
// install-wide one: the own-actor filter below already stays inside
// what the scope allows, and a boundary that only exists in one arm
// of an `if` is one refactor away from not existing.
$query = $this->activityLog->apply(
ActivityLog::query()->where('origin', ActivityOrigin::Api),
$viewer,
);
if (! $installWide) { if (! $installWide) {
$query->where('actor_id', $viewer->id); $query->where('actor_id', $viewer->id);
app/Modules/Api/Support/ProblemDetails.php
+4 -2
View File
@@ -5,6 +5,7 @@ declare(strict_types=1);
namespace App\Modules\Api\Support; namespace App\Modules\Api\Support;
use App\Modules\Platform\Capabilities\CapabilityUnavailable; use App\Modules\Platform\Capabilities\CapabilityUnavailable;
use App\Support\ApiSurface;
use Illuminate\Auth\Access\AuthorizationException; use Illuminate\Auth\Access\AuthorizationException;
use Illuminate\Auth\AuthenticationException; use Illuminate\Auth\AuthenticationException;
use Illuminate\Database\Eloquent\ModelNotFoundException; use Illuminate\Database\Eloquent\ModelNotFoundException;
@@ -16,7 +17,8 @@ use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
use Throwable; use Throwable;
/** /**
* RFC 7807 error bodies for /api/* only. * RFC 7807 error bodies for the API surface only -- see ApiSurface, which
* is the same question the capability middleware asks.
* *
* Two properties this class exists to guarantee: * Two properties this class exists to guarantee:
* *
@@ -55,7 +57,7 @@ class ProblemDetails
public function shouldHandle(Request $request): bool public function shouldHandle(Request $request): bool
{ {
return $request->is('api/*'); return ApiSurface::matches($request);
} }
public function render(Request $request, Throwable $e): JsonResponse public function render(Request $request, Throwable $e): JsonResponse
app/Modules/Audit/Http/Controllers/DashboardController.php
+35 -14
View File
@@ -12,8 +12,10 @@ use App\Modules\Audit\ActivityLog;
use App\Modules\Audit\ActivityLogScope; use App\Modules\Audit\ActivityLogScope;
use App\Modules\Audit\ActivityPresenter; use App\Modules\Audit\ActivityPresenter;
use App\Modules\Audit\DashboardWidgetPreferences; use App\Modules\Audit\DashboardWidgetPreferences;
use Illuminate\Support\Facades\Event;
use App\Modules\Clients\ClientStorageUsage; use App\Modules\Clients\ClientStorageUsage;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Files\Delivery\FileDelivery;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Groups\Models\Group; use App\Modules\Groups\Models\Group;
use App\Modules\Identity\UserType; use App\Modules\Identity\UserType;
@@ -51,6 +53,7 @@ class DashboardController extends Controller
private readonly Settings $settings, private readonly Settings $settings,
private readonly ApiUsage $apiUsage, private readonly ApiUsage $apiUsage,
private readonly StorageDurability $storageDurability, private readonly StorageDurability $storageDurability,
private readonly FileDelivery $fileDelivery,
private readonly Installation $installation, private readonly Installation $installation,
private readonly TimezoneRegistry $timezones, private readonly TimezoneRegistry $timezones,
private readonly SystemEnvironment $environment, private readonly SystemEnvironment $environment,
@@ -155,8 +158,12 @@ class DashboardController extends Controller
* *
* Every boundary is built in the viewer's zone, so "last week" ends * Every boundary is built in the viewer's zone, so "last week" ends
* when their evening does and not at whatever hour UTC midnight falls * when their evening does and not at whatever hour UTC midnight falls
* on for them. The returned instants are still absolute — only the * on for them. The instants are absolute, but they carry that zone —
* day edges moved — so they compare against the UTC column directly. * and a Carbon handed to the query builder is formatted in its own
* zone, offset discarded, so comparing one against a UTC column asks
* a question nine hours out for a viewer in Tokyo. transferSeries()
* converts before it compares; the day cursor there keeps them as
* they are, because that half really is about the viewer's calendar.
* *
* @return array{0: Carbon, 1: Carbon, 2: string} * @return array{0: Carbon, 1: Carbon, 2: string}
*/ */
@@ -248,7 +255,13 @@ class DashboardController extends Controller
$rows = ActivityLog::query() $rows = ActivityLog::query()
->whereIn('action', [Action::FileUploaded->value, ...array_map(fn (Action $a): string => $a->value, $downloadActions)]) ->whereIn('action', [Action::FileUploaded->value, ...array_map(fn (Action $a): string => $a->value, $downloadActions)])
->whereBetween('created_at', [$from, $to]) // In UTC, because that is what the column is. The query
// builder formats a Carbon in whatever zone the object holds
// and drops the offset, so passing the viewer's midnight
// straight in compares "2026-08-22 00:00:00" against a UTC
// column — nine hours of somebody else's day, at both ends,
// for a viewer in Tokyo.
->whereBetween('created_at', [$from->copy()->utc(), $to->copy()->utc()])
->get(['action', 'actor_type', 'created_at']) ->get(['action', 'actor_type', 'created_at'])
// Bucketed by the viewer's calendar day. Grouping on the UTC // Bucketed by the viewer's calendar day. Grouping on the UTC
// one puts an evening upload from anywhere west of Greenwich // one puts an evening upload from anywhere west of Greenwich
@@ -467,7 +480,7 @@ class DashboardController extends Controller
} }
/** /**
* @return array<string, string|int|bool|array<string, string|null>|null> * @return array<string, array<string, bool|string|null>|bool|int|string|null>
*/ */
private function systemInfo(): array private function systemInfo(): array
{ {
@@ -492,28 +505,36 @@ class DashboardController extends Controller
// Installation. Always present, unlike storage_durability, which // Installation. Always present, unlike storage_durability, which
// is null whenever the durability question does not apply. // is null whenever the durability question does not apply.
'install_kind' => $this->installation->kind()->value, 'install_kind' => $this->installation->kind()->value,
// How downloads leave the server, and whether that was
// detected or stated. Reported even when it is the fast path:
// "my downloads are handed to the web server" is worth being
// able to confirm at a glance, not only worth warning about
// when it is false — the same reasoning as storage_durability.
'file_delivery' => $this->fileDelivery->describe(),
]; ];
} }
private function clientDashboard(User $client): Response private function clientDashboard(User $client): Response
{ {
$assignedFiles = File::query()->whereHas('assignments', function ($query) use ($client): void { // File::scopeVisibleToClient is the single source of truth for
$query->where(function ($direct) use ($client): void { // client file access, and this page has to agree with the portal it
$direct->where('assignable_type', User::class)->where('assignable_id', $client->id); // introduces. Restating the assignment half here made it disagree
})->orWhere(function ($viaGroup) use ($client): void { // in both directions: it counted expired files, which the scope
$viaGroup->where('assignable_type', Group::class) // ends by excluding and /my-files therefore never shows, and it
->whereIn('assignable_id', $client->memberOfGroups()->pluck('groups.id')); // missed everything that reaches a client another way — a file in a
}); // folder shared with them, their own portal upload, and a revision,
}); // which owns no assignment row and inherits its original's
// recipients.
$visibleFiles = File::query()->visibleToClient($client);
return Inertia::render('portal/dashboard', [ return Inertia::render('portal/dashboard', [
'files_count' => (clone $assignedFiles)->count(), 'files_count' => (clone $visibleFiles)->count(),
'groups_count' => $client->memberOfGroups()->where('public', true)->count(), 'groups_count' => $client->memberOfGroups()->where('public', true)->count(),
'storage' => [ 'storage' => [
'used_bytes' => $this->storageUsage->usedBytes($client), 'used_bytes' => $this->storageUsage->usedBytes($client),
'quota_bytes' => $this->storageUsage->quotaBytes($client) ?: null, 'quota_bytes' => $this->storageUsage->quotaBytes($client) ?: null,
], ],
'latest_files' => $assignedFiles->orderByDesc('created_at')->limit(5)->get() 'latest_files' => $visibleFiles->orderByDesc('created_at')->limit(5)->get()
->map(fn (File $file): array => [ ->map(fn (File $file): array => [
'id' => $file->id, 'id' => $file->id,
'name' => $file->name, 'name' => $file->name,
app/Modules/Audit/Http/Controllers/DashboardWidgetPreferencesController.php
+8 -2
View File
@@ -45,8 +45,14 @@ class DashboardWidgetPreferencesController extends Controller
$validated = $request->validate([ $validated = $request->validate([
'columns' => ['required', 'integer', 'between:1,4'], 'columns' => ['required', 'integer', 'between:1,4'],
'widgets' => ['required', 'array'], // Bounded by the allowlist itself, and unique on the key. The
'widgets.*.widget_key' => ['required', 'string', Rule::in(self::WIDGET_KEYS)], // Rule::in below checks each value; it says nothing about how
// many there are or whether they repeat, and the loop writes
// one row per element. A layout has at most one entry per
// widget, so anything longer than the registry is not a layout
// this screen could have produced.
'widgets' => ['required', 'array', 'max:'.count(self::WIDGET_KEYS)],
'widgets.*.widget_key' => ['required', 'string', 'distinct', Rule::in(self::WIDGET_KEYS)],
'widgets.*.enabled' => ['required', 'boolean'], 'widgets.*.enabled' => ['required', 'boolean'],
'widgets.*.column_index' => ['required', 'integer', 'between:0,3'], 'widgets.*.column_index' => ['required', 'integer', 'between:0,3'],
'widgets.*.position' => ['required', 'integer', 'min:0'], 'widgets.*.position' => ['required', 'integer', 'min:0'],
app/Modules/Clients/ClientAccounts.php
+111
View File
@@ -0,0 +1,111 @@
<?php
declare(strict_types=1);
namespace App\Modules\Clients;
use App\Models\User;
use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger;
use App\Modules\Clients\Notifications\ClientWelcomeNotification;
use App\Modules\Identity\Models\Role;
use App\Modules\Identity\Permissions\SystemRole;
use App\Modules\Identity\UserType;
use App\Modules\Platform\Seats\SeatAllowance;
use App\Modules\Platform\Settings\Setting;
use App\Modules\Platform\Settings\Settings;
/**
* Creating a client account — the rules and the side effects, shared by
* every surface that makes one.
*
* The same argument StaffAccounts makes for staff. What a client account
* *is* — its type, its role, an active flag, a quota where zero means
* "inherit the site default" rather than "none" — is a set of invariants,
* and an invariant enforced in one controller and re-implemented in
* another is one that will eventually hold in only one of them. There are
* three surfaces onto this now: the staff screens, `/api/v1/clients`, and
* the platform control plane in the private package, which reaches this
* by name because it cannot import a host class.
*
* What stays with the caller is what genuinely differs: the shape of the
* request, its validation rules, its response, and anything about *who is
* asking* — a client-scoped staff member gaining the client on their own
* roster is a fact about the creator, not about the account created.
*
* **Not to be confused with ClientProvisioning**, which sits beside it and
* handles the other half: an account that comes into existence without
* anybody deciding to create it — the public registration form, and a
* first successful LDAP sign-in. The policies genuinely differ rather than
* merely duplicating. An account made here is approved and verified by
* construction, because somebody who already knows who this is asked for
* it; one made there may wait for approval, joins a configured group, and
* tells the administrators it arrived.
*/
class ClientAccounts
{
public function __construct(
private readonly ActivityLogger $activity,
private readonly SeatAllowance $seats,
private readonly Settings $settings,
) {}
/**
* @param int $storageQuotaMb 0 means no per-account quota and
* inherits the site default at
* enforcement time — see
* ClientStorageUsage::quotaMb(). It does
* not mean unlimited.
* @param bool $welcome whether this installation should email the
* new account. A caller that sends its own
* welcome passes false rather than having the
* customer receive two.
*/
public function create(
string $name,
string $email,
string $password,
int $storageQuotaMb = 0,
bool $welcome = true,
string $emailField = 'email',
): User {
// Before anything is written, and deliberately not left to the
// caller. The platform sets this cap and the platform is also what
// calls the control plane — so enforcing it here is what stops a
// leaked control token minting accounts without limit. A guard
// that only ran on the surfaces that remembered it would not be a
// guard.
$this->seats->guardClient($emailField);
$client = User::create([
'type' => UserType::Client,
'active' => true,
'account_requested' => false,
'role_id' => Role::query()->where('name', SystemRole::Client->value)->value('id'),
'name' => $name,
'email' => $email,
'password' => $password,
'storage_quota_mb' => $storageQuotaMb,
]);
// forceFill, and not part of the create() array above: like
// StaffAccounts, email_verified_at is deliberately absent from
// User::$fillable — where an account stands is a security decision
// rather than an attribute — so mass assignment drops it in
// silence. Every client-creation path used to pass it in that
// array and lose it. The intent is real: an account created by
// somebody who already knows who this is has no address to
// confirm and nobody to confirm it to. (Inert today, since
// MustVerifyEmail is not enabled on the model, but the column is
// what a later switch would read.)
$client->forceFill(['email_verified_at' => now()])->save();
$this->activity->log(Action::UserCreated, subject: $client);
if ($welcome && $this->settings->get(Setting::EmailNotificationsEnabled) === true) {
$client->notify(new ClientWelcomeNotification);
}
return $client;
}
}
app/Modules/Clients/ClientPortalCustomFields.php
+18 -2
View File
@@ -158,7 +158,23 @@ class ClientPortalCustomFields
*/ */
private function isLocked(ClientCustomField $field, BaseCollection $values): bool private function isLocked(ClientCustomField $field, BaseCollection $values): bool
{ {
return $field->client_editability === ClientFieldEditability::EditableOnce if ($field->client_editability !== ClientFieldEditability::EditableOnce) {
&& filled($values->get($field->id)); return false;
}
$stored = $values->get($field->id);
// A checkbox has a stored value from the first save onwards: an
// unticked box is written as '0', and filled('0') is true. Asking
// "is anything stored" therefore locked the field on the first save
// of the form it sits on, whatever the client had chosen — and a
// box they never ticked can then never be ticked. '0' is the
// absence of a decision, which is the state the other types express
// as null, so it is what an unlocked checkbox looks like.
if ($field->type === ClientCustomFieldType::Checkbox) {
return $stored === '1';
}
return filled($stored);
} }
} }
app/Modules/Clients/ClientProvisioning.php
+16
View File
@@ -48,6 +48,22 @@ class ClientProvisioning
return $this->settings->get(Setting::ClientsAutoApprove) === true; return $this->settings->get(Setting::ClientsAutoApprove) === true;
} }
/**
* Whether an address is free for a new account.
*
* The unique index on `email` spans soft-deleted rows — AvailableEmailRule
* is built on exactly that, so a deleted account keeps its address until
* erasure takes the row away. The registration form learns this from
* validation. The machine paths have no form to validate: a directory or
* an identity provider hands over an address and provision() inserts it,
* so without asking first the insert raises a QueryException in the
* middle of somebody's sign-in.
*/
public function addressIsFree(string $email): bool
{
return ! User::withTrashed()->where('email', $email)->exists();
}
/** /**
* @param bool|null $autoApprove Null asks Setting::ClientsAutoApprove, * @param bool|null $autoApprove Null asks Setting::ClientsAutoApprove,
* which is the right question for the * which is the right question for the
app/Modules/Clients/ClientStorageUsage.php
+43 -5
View File
@@ -28,10 +28,9 @@ class ClientStorageUsage
/** /**
* A client's own storage_quota_mb of 0 means "no custom quota set" — * A client's own storage_quota_mb of 0 means "no custom quota set" —
* it inherits Setting::DefaultClientStorageQuotaMb instead of being * it inherits the installation's default instead of being unlimited,
* unlimited, so a site-wide default (once set) also protects clients * so a default (once set) also protects clients who never got an
* who never got an explicit quota, including self-registered ones. * explicit quota, including self-registered ones.
* The site default itself being 0 is what actually means unlimited.
* *
* @return int 0 means unlimited. * @return int 0 means unlimited.
*/ */
@@ -39,7 +38,46 @@ class ClientStorageUsage
{ {
return $client->storage_quota_mb > 0 return $client->storage_quota_mb > 0
? $client->storage_quota_mb ? $client->storage_quota_mb
: (int) $this->settings->get(Setting::DefaultClientStorageQuotaMb); : $this->defaultQuotaMb();
}
/**
* What a client with no quota of their own actually gets.
*
* Three sources, narrowest first, and the third is why this is a
* method rather than a `Settings::get()` at the point of use.
*
* `Setting::DefaultClientStorageQuotaMb` belongs to whoever runs the
* installation, and its default is 0 — which means unlimited. That is
* the right default for somebody setting up their own install, and the
* wrong one for an installation a platform operates on other people's
* behalf: there, an account that arrived without an explicit quota has
* no ceiling at all, which on a shared installation is one account
* away from unmetered hosting.
*
* So a platform may set a floor in the environment, exactly as it sets
* the seat caps, and for the same reason those are not settings: it is
* not a preference the installation's administrator is expressing, it
* is the shape of what was sold. It applies only where the setting says
* nothing, so an administrator who has chosen a number keeps it, and an
* install with no platform behind it is unaffected.
*
* Unset and zero are the same answer here, on purpose: a platform that
* wanted no ceiling would not set the variable.
*
* @return int 0 means unlimited.
*/
public function defaultQuotaMb(): int
{
$site = (int) $this->settings->get(Setting::DefaultClientStorageQuotaMb);
if ($site > 0) {
return $site;
}
$floor = config('projectsend.platform.default_client_quota_mb');
return is_numeric($floor) ? max(0, (int) $floor) : 0;
} }
/** /**
app/Modules/Clients/Http/Controllers/Api/ClientsController.php
+70 -21
View File
@@ -9,6 +9,7 @@ use App\Models\User;
use App\Modules\Api\Support\PollingQuery; use App\Modules\Api\Support\PollingQuery;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Clients\ClientAccounts;
use App\Modules\Clients\ClientCustomFieldType; use App\Modules\Clients\ClientCustomFieldType;
use App\Modules\Clients\ClientStorageUsage; use App\Modules\Clients\ClientStorageUsage;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
@@ -22,13 +23,11 @@ use App\Modules\Files\DeletedAccountContent;
use App\Modules\Identity\AccountContentDeletion; use App\Modules\Identity\AccountContentDeletion;
use App\Modules\Identity\Erasure\AvailableEmailRule; use App\Modules\Identity\Erasure\AvailableEmailRule;
use App\Modules\Identity\Erasure\ErasureSchedule; use App\Modules\Identity\Erasure\ErasureSchedule;
use App\Modules\Identity\Models\Role;
use App\Modules\Identity\Permissions\SystemRole;
use App\Modules\Identity\TwoFactor\TwoFactorAdministration; use App\Modules\Identity\TwoFactor\TwoFactorAdministration;
use App\Modules\Identity\UserType;
use App\Modules\Platform\Settings\Setting; use App\Modules\Platform\Settings\Setting;
use App\Modules\Platform\Settings\Settings; use App\Modules\Platform\Settings\Settings;
use Illuminate\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Collection;
use Illuminate\Http\JsonResponse; use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Http\Resources\Json\AnonymousResourceCollection; use Illuminate\Http\Resources\Json\AnonymousResourceCollection;
@@ -61,6 +60,7 @@ class ClientsController extends Controller
private readonly AccountContentDeletion $accountDeletion, private readonly AccountContentDeletion $accountDeletion,
private readonly StaffLibraryScope $scope, private readonly StaffLibraryScope $scope,
private readonly SeatAllowance $seats, private readonly SeatAllowance $seats,
private readonly ClientAccounts $clients,
private readonly ErasureSchedule $erasure, private readonly ErasureSchedule $erasure,
) {} ) {}
@@ -117,8 +117,6 @@ class ClientsController extends Controller
public function store(Request $request): JsonResponse public function store(Request $request): JsonResponse
{ {
$this->seats->guardClient();
$validated = $request->validate([ $validated = $request->validate([
'name' => ['required', 'string', 'max:255'], 'name' => ['required', 'string', 'max:255'],
'email' => ['required', 'string', 'lowercase', 'email', 'max:255', new AvailableEmailRule], 'email' => ['required', 'string', 'lowercase', 'email', 'max:255', new AvailableEmailRule],
@@ -137,24 +135,39 @@ class ClientsController extends Controller
$validated['custom_field_values'] = $this->validateCustomFieldValues($request); $validated['custom_field_values'] = $this->validateCustomFieldValues($request);
$client = User::create([ // The invariants — the seat guard, the type, the role, the quota's
'type' => UserType::Client, // "0 means inherit" — live in ClientAccounts, shared with the staff
'active' => true, // screens and with the platform control plane. What stays here is
'account_requested' => false, // this surface's own business: its validation, its custom fields,
'role_id' => Role::query()->where('name', SystemRole::Client->value)->value('id'), // and who the creator is.
'name' => $validated['name'], $client = $this->clients->create(
'email' => $validated['email'], name: $validated['name'],
'password' => $validated['password'], email: $validated['email'],
// 0 means "no custom quota" and inherits the site default at password: $validated['password'],
// enforcement time — see ClientStorageUsage::quotaMb(). storageQuotaMb: $validated['storage_quota_mb'] ?? 0,
'storage_quota_mb' => $validated['storage_quota_mb'] ?? 0, welcome: false,
'email_verified_at' => now(), );
]);
$this->activity->log(Action::UserCreated, subject: $client); $creator = $request->user();
assert($creator !== null);
// A client-scoped creator would otherwise lose the client they just
// made. guardTarget() answers 404 for anything off their roster, so
// the record they created is not theirs to open, and
// StaffLibraryScope::clients() leaves it out of their list as well —
// the client exists, is welcomed by email, and is invisible to the
// person who made it. Their own roster is where a client they
// created belongs; an unscoped creator has no roster to add to.
if ($creator->isClientScoped()) {
$creator->assignedClients()->attach($client->id);
}
$this->saveCustomFieldValues($client, $validated['custom_field_values'] ?? []); $this->saveCustomFieldValues($client, $validated['custom_field_values'] ?? []);
// Sent here rather than inside ClientAccounts so the custom fields
// are already saved when it goes: a welcome that arrives before
// the account is finished describes an account that does not quite
// exist yet.
if ($this->settings->get(Setting::EmailNotificationsEnabled) === true) { if ($this->settings->get(Setting::EmailNotificationsEnabled) === true) {
$client->notify(new ClientWelcomeNotification); $client->notify(new ClientWelcomeNotification);
} }
@@ -191,7 +204,11 @@ class ClientsController extends Controller
$client->storage_quota_mb = $validated['storage_quota_mb'] ?? 0; $client->storage_quota_mb = $validated['storage_quota_mb'] ?? 0;
} }
// Approval, and so the moment the seat is spent — same rule the
// web edit screen and approve() answer to. Inside the branch, so a
// capped installation can still edit a client it already holds.
if (($validated['active'] ?? false) && $client->account_requested) { if (($validated['active'] ?? false) && $client->account_requested) {
$this->seats->guardClient('active');
$client->account_requested = false; $client->account_requested = false;
} }
@@ -202,7 +219,7 @@ class ClientsController extends Controller
$client->save(); $client->save();
if (array_key_exists('custom_field_values', $validated)) { if (array_key_exists('custom_field_values', $validated)) {
$this->saveCustomFieldValues($client, $validated['custom_field_values']); $this->patchCustomFieldValues($client, $validated['custom_field_values']);
} }
$this->activity->log(Action::UserUpdated, subject: $client); $this->activity->log(Action::UserUpdated, subject: $client);
@@ -360,11 +377,43 @@ class ClientsController extends Controller
} }
/** /**
* Every field, whether or not the request named it — a new client has
* no values yet, and create() is not a partial update.
*
* @param array<int, mixed> $values field id => submitted value * @param array<int, mixed> $values field id => submitted value
*/ */
private function saveCustomFieldValues(User $client, array $values): void private function saveCustomFieldValues(User $client, array $values): void
{ {
foreach (ClientCustomField::query()->get() as $field) { $this->writeCustomFieldValues($client, ClientCustomField::query()->get(), $values);
}
/**
* Only the fields the request actually named.
*
* PATCH semantics, the same rule update() applies to every other
* column: an absent key means "leave alone", not "clear". Sharing
* create()'s "write every field" pass here emptied every custom field
* the caller had not mentioned, which is silent data loss on a request
* that looked like it changed one thing.
*
* @param array<int, mixed> $values field id => submitted value
*/
private function patchCustomFieldValues(User $client, array $values): void
{
$this->writeCustomFieldValues(
$client,
ClientCustomField::query()->whereIn('id', array_keys($values))->get(),
$values,
);
}
/**
* @param Collection<int, ClientCustomField> $fields
* @param array<int, mixed> $values field id => submitted value
*/
private function writeCustomFieldValues(User $client, Collection $fields, array $values): void
{
foreach ($fields as $field) {
$submitted = $values[$field->id] ?? null; $submitted = $values[$field->id] ?? null;
$value = $field->type === ClientCustomFieldType::Checkbox $value = $field->type === ClientCustomFieldType::Checkbox
? ($submitted ? '1' : '0') ? ($submitted ? '1' : '0')
app/Modules/Clients/Http/Controllers/ClientsController.php
+73 -31
View File
@@ -8,6 +8,7 @@ use App\Http\Controllers\Controller;
use App\Models\User; use App\Models\User;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Clients\ClientAccounts;
use App\Modules\Clients\ClientCustomFieldType; use App\Modules\Clients\ClientCustomFieldType;
use App\Modules\Clients\ClientStorageUsage; use App\Modules\Clients\ClientStorageUsage;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
@@ -20,10 +21,7 @@ use App\Modules\Files\DeletedAccountContent;
use App\Modules\Identity\AccountContentDeletion; use App\Modules\Identity\AccountContentDeletion;
use App\Modules\Identity\Erasure\AvailableEmailRule; use App\Modules\Identity\Erasure\AvailableEmailRule;
use App\Modules\Identity\Erasure\ErasureSchedule; use App\Modules\Identity\Erasure\ErasureSchedule;
use App\Modules\Identity\Models\Role;
use App\Modules\Identity\Permissions\SystemRole;
use App\Modules\Identity\TwoFactor\TwoFactorAdministration; use App\Modules\Identity\TwoFactor\TwoFactorAdministration;
use App\Modules\Identity\UserType;
use App\Modules\Platform\Settings\Setting; use App\Modules\Platform\Settings\Setting;
use App\Modules\Platform\Settings\Settings; use App\Modules\Platform\Settings\Settings;
use App\Support\Pagination; use App\Support\Pagination;
@@ -51,6 +49,7 @@ class ClientsController extends Controller
private readonly AccountContentDeletion $accountDeletion, private readonly AccountContentDeletion $accountDeletion,
private readonly StaffLibraryScope $scope, private readonly StaffLibraryScope $scope,
private readonly SeatAllowance $seats, private readonly SeatAllowance $seats,
private readonly ClientAccounts $clients,
private readonly ErasureSchedule $erasure, private readonly ErasureSchedule $erasure,
) {} ) {}
@@ -98,24 +97,50 @@ class ClientsController extends Controller
'clients' => $clients->items(), 'clients' => $clients->items(),
'pagination' => Pagination::meta($clients), 'pagination' => Pagination::meta($clients),
'filters' => $filters, 'filters' => $filters,
'reassign_candidates' => $this->accountDeletion->candidates(), // Only for somebody who may actually reassign: the picker is
// part of the delete dialog, and React filtering it out of the
// page is not the same as it never being on the page.
'reassign_candidates' => $viewer->can('delete_clients')
? $this->accountDeletion->candidates($viewer)
: [],
// Null on a self-hosted install: no limit, nothing to say.
'seats' => $this->seats->clientState(),
]); ]);
} }
public function create(): Response public function create(): RedirectResponse|Response
{ {
// The same courtesy UsersController::create() does: a full
// installation is an ordinary state on a managed plan, so say so
// before somebody fills in a form that cannot be submitted. The
// guard in store() is still the rule; this is only the door.
$seats = $this->seats->clientState();
if ($seats !== null && $seats['full']) {
return redirect()->route('clients.index')->with('error', $seats['message']);
}
return Inertia::render('clients/create', [ return Inertia::render('clients/create', [
'custom_fields' => $this->customFieldDefinitions(), 'custom_fields' => $this->customFieldDefinitions(),
'default_storage_quota_mb' => (int) $this->settings->get(Setting::DefaultClientStorageQuotaMb), // The resolved default, not the raw setting: a platform can put
// a floor under it from the environment, and both screens
// present this as what will actually happen rather than as a
// value being edited. The edit screen mirrors quotaMb()'s
// resolution client-side to draw the usage bar, and handing it
// the effective number is what keeps that mirror correct
// without it having to know floors exist.
//
// The Client settings form deliberately still reads the raw
// setting (ClientSettingsController): that field is edited and
// saved back, so prefilling it with a floor would write the
// platform's number into the setting as the administrator's own
// choice, where it would outlive the floor.
'default_storage_quota_mb' => $this->storageUsage->defaultQuotaMb(),
]); ]);
} }
public function store(Request $request): RedirectResponse public function store(Request $request): RedirectResponse
{ {
// A client created here is approved by construction, so it counts
// immediately — unlike a self-registration awaiting a decision.
$this->seats->guardClient();
$validated = $request->validate(array_merge([ $validated = $request->validate(array_merge([
'name' => ['required', 'string', 'max:255'], 'name' => ['required', 'string', 'max:255'],
'email' => ['required', 'string', 'lowercase', 'email', 'max:255', new AvailableEmailRule], 'email' => ['required', 'string', 'lowercase', 'email', 'max:255', new AvailableEmailRule],
@@ -123,24 +148,33 @@ class ClientsController extends Controller
'storage_quota_mb' => ['nullable', 'integer', 'min:0'], 'storage_quota_mb' => ['nullable', 'integer', 'min:0'],
], $this->customFieldRules())); ], $this->customFieldRules()));
$client = User::create([ // The seat guard, the type, the role, and the quota's "0 means
'type' => UserType::Client, // inherit the site default" all live in ClientAccounts, shared
'active' => true, // with the API and the control plane. A client created here is
'account_requested' => false, // approved by construction, so it counts against the cap
'role_id' => Role::query()->where('name', SystemRole::Client->value)->value('id'), // immediately — unlike a self-registration awaiting a decision.
'name' => $validated['name'], // The welcome waits until the custom fields are saved below.
'email' => $validated['email'], $client = $this->clients->create(
'password' => $validated['password'], name: $validated['name'],
// 0 (including an omitted field) means "no custom quota" — email: $validated['email'],
// it inherits Setting::DefaultClientStorageQuotaMb at password: $validated['password'],
// enforcement time (see ClientStorageUsage::quotaMb()), not storageQuotaMb: $validated['storage_quota_mb'] ?? 0,
// baked in here, so a later change to the site default welcome: false,
// keeps applying to this client automatically. );
'storage_quota_mb' => $validated['storage_quota_mb'] ?? 0,
'email_verified_at' => now(),
]);
$this->activity->log(Action::UserCreated, subject: $client); $creator = $request->user();
assert($creator !== null);
// A client-scoped creator would otherwise lose the client they just
// made. guardTarget() answers 404 for anything off their roster, so
// the record they created is not theirs to open, and
// StaffLibraryScope::clients() leaves it out of their list as well —
// the client exists, is welcomed by email, and is invisible to the
// person who made it. Their own roster is where a client they
// created belongs; an unscoped creator has no roster to add to.
if ($creator->isClientScoped()) {
$creator->assignedClients()->attach($client->id);
}
$this->saveCustomFieldValues($client, $validated['custom_field_values'] ?? []); $this->saveCustomFieldValues($client, $validated['custom_field_values'] ?? []);
@@ -154,7 +188,7 @@ class ClientsController extends Controller
// Fall back to the create form: it shares this route's own gate, so // Fall back to the create form: it shares this route's own gate, so
// it is reachable by exactly whoever just created the record, and // it is reachable by exactly whoever just created the record, and
// the success toast shows there. // the success toast shows there.
$target = $request->user()?->can('edit_clients') $target = $creator->can('edit_clients')
? redirect()->route('clients.edit', $client) ? redirect()->route('clients.edit', $client)
: redirect()->route('clients.create'); : redirect()->route('clients.create');
@@ -195,14 +229,17 @@ class ClientsController extends Controller
'storage_quota_mb' => $client->storage_quota_mb, 'storage_quota_mb' => $client->storage_quota_mb,
'two_factor_enabled' => $client->hasTwoFactorEnabled(), 'two_factor_enabled' => $client->hasTwoFactorEnabled(),
], ],
'default_storage_quota_mb' => (int) $this->settings->get(Setting::DefaultClientStorageQuotaMb), // Resolved, not raw — see create() above.
'default_storage_quota_mb' => $this->storageUsage->defaultQuotaMb(),
'storage_used_mb' => (int) ceil($this->storageUsage->usedBytes($client) / 1024 / 1024), 'storage_used_mb' => (int) ceil($this->storageUsage->usedBytes($client) / 1024 / 1024),
'custom_fields' => $this->customFieldDefinitions(), 'custom_fields' => $this->customFieldDefinitions(),
'custom_field_values' => ClientCustomFieldValue::query() 'custom_field_values' => ClientCustomFieldValue::query()
->where('user_id', $client->id) ->where('user_id', $client->id)
->pluck('value', 'client_custom_field_id'), ->pluck('value', 'client_custom_field_id'),
'content' => $this->accountContent->summarize($client), 'content' => $this->accountContent->summarize($client),
'reassign_candidates' => $this->accountDeletion->candidates($client->id), 'reassign_candidates' => $request->user()?->can('delete_clients') === true
? $this->accountDeletion->candidates($request->user(), $client->id)
: [],
]); ]);
} }
@@ -234,8 +271,13 @@ class ClientsController extends Controller
]); ]);
// Activating a pending account through the edit screen counts as // Activating a pending account through the edit screen counts as
// approval and clears the request flag. // approval and clears the request flag — which is the moment a
// seat is spent, so the cap is asked here for the same reason
// AccountRequestsController::approve() asks it one screen over.
// Inside the branch, not above it: an installation at its cap must
// still be able to rename a client it already has.
if ($client->account_requested && $validated['active']) { if ($client->account_requested && $validated['active']) {
$this->seats->guardClient('active');
$client->account_requested = false; $client->account_requested = false;
} }
app/Modules/Comments/Access/VisibleCommentScope.php
+17 -2
View File
@@ -10,6 +10,7 @@ use App\Modules\Comments\GuestCommentIdentity;
use App\Modules\Comments\Models\FileComment; use App\Modules\Comments\Models\FileComment;
use App\Modules\Files\Access\ShareTargets; use App\Modules\Files\Access\ShareTargets;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Files\Access\ViewableFileScope;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Files\Models\Folder; use App\Modules\Files\Models\Folder;
use App\Modules\Identity\UserType; use App\Modules\Identity\UserType;
@@ -51,6 +52,7 @@ class VisibleCommentScope
{ {
public function __construct( public function __construct(
private readonly StaffLibraryScope $scope, private readonly StaffLibraryScope $scope,
private readonly ViewableFileScope $viewable,
private readonly ShareTargets $shareTargets, private readonly ShareTargets $shareTargets,
private readonly GuestCommentIdentity $guests, private readonly GuestCommentIdentity $guests,
) {} ) {}
@@ -123,6 +125,13 @@ class VisibleCommentScope
* way around the visibility model** — moderating means deciding about * way around the visibility model** — moderating means deciding about
* comments you can already see. * comments you can already see.
* *
* Which is why the files come from ViewableFileScope rather than from
* StaffLibraryScope: FilePolicy::view() is a permission half AND a
* library half, and narrowing by the library alone would hand every
* comment in the installation to a role holding moderate_comments and
* none of the three file keys — somebody who gets a 403 on every file
* these comments are about.
*
* Staff only. A client has no cross-file view of comments and asking * Staff only. A client has no cross-file view of comments and asking
* for one is a mistake rather than an empty result, but returning * for one is a mistake rather than an empty result, but returning
* nothing is the safe way to be wrong. * nothing is the safe way to be wrong.
@@ -136,7 +145,7 @@ class VisibleCommentScope
} }
return $this->applyVisibility( return $this->applyVisibility(
FileComment::query()->whereIn('file_id', $this->scope->files($viewer)->select('files.id')), FileComment::query()->whereIn('file_id', $this->viewable->for($viewer)->select('files.id')),
$viewer, $viewer,
// Publicness is a property of each file, so it cannot be one // Publicness is a property of each file, so it cannot be one
// value for a query spanning many. It does not have to be: the // value for a query spanning many. It does not have to be: the
@@ -156,6 +165,12 @@ class VisibleCommentScope
* than about what this viewer may read, and a moderator who cannot see * than about what this viewer may read, and a moderator who cannot see
* a particular client's thread must still be told the file has * a particular client's thread must still be told the file has
* something waiting. * something waiting.
*
* The file boundary is still the same one, though. ViewableFileScope
* rather than StaffLibraryScope: which files is the part that varies
* per client, whether any is the part that does not, and a badge
* counting the whole installation for somebody who may open none of it
* is a number about other people's files.
*/ */
public function pendingTotal(User $viewer): int public function pendingTotal(User $viewer): int
{ {
@@ -165,7 +180,7 @@ class VisibleCommentScope
return FileComment::query() return FileComment::query()
->whereNull('approved_at') ->whereNull('approved_at')
->whereIn('file_id', $this->scope->files($viewer)->select('files.id')) ->whereIn('file_id', $this->viewable->for($viewer)->select('files.id'))
->count(); ->count();
} }
app/Modules/Comments/CommentPresenter.php
+9 -4
View File
@@ -141,14 +141,19 @@ class CommentPresenter
]; ];
} }
/**
* Asked of the column, not of the relation — the same rule
* isFromGuest() and authorName() follow. Since author() reads a
* deleted account too this would now answer correctly either way; it
* is written this way so the next reader does not re-derive "no
* author row means guest", which is what it used to mean here.
*/
private function authorType(FileComment $comment): string private function authorType(FileComment $comment): string
{ {
$author = $comment->author; if ($comment->isFromGuest()) {
if ($author === null) {
return 'guest'; return 'guest';
} }
return $author->isStaff() ? 'staff' : 'client'; return $comment->author?->isStaff() === true ? 'staff' : 'client';
} }
} }
app/Modules/Comments/FileCommentPolicy.php
+11
View File
@@ -8,6 +8,7 @@ use App\Models\User;
use App\Modules\Comments\Access\VisibleCommentScope; use App\Modules\Comments\Access\VisibleCommentScope;
use App\Modules\Comments\Models\FileComment; use App\Modules\Comments\Models\FileComment;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Files\Access\ViewableFileScope;
use Illuminate\Support\Facades\Gate; use Illuminate\Support\Facades\Gate;
/** /**
@@ -22,6 +23,7 @@ class FileCommentPolicy
private readonly VisibleCommentScope $scope, private readonly VisibleCommentScope $scope,
private readonly CommentingRules $rules, private readonly CommentingRules $rules,
private readonly StaffLibraryScope $library, private readonly StaffLibraryScope $library,
private readonly ViewableFileScope $viewable,
) {} ) {}
public function view(User $user, FileComment $comment): bool public function view(User $user, FileComment $comment): bool
@@ -69,6 +71,15 @@ class FileCommentPolicy
return false; return false;
} }
// Moderating is deciding about comments you can already see, so the
// permission half of file reading is part of the answer in both
// forms. Without one of the three file keys this user gets a 403 on
// every file these comments are about, and approving one hands back
// its body — so this is a reading door, not only a writing one.
if (! $this->viewable->permitsAnyFile($user)) {
return false;
}
if ($comment === null || ! $user->isClientScoped()) { if ($comment === null || ! $user->isClientScoped()) {
return true; return true;
} }
app/Modules/Comments/FileComments.php
+18 -1
View File
@@ -220,10 +220,27 @@ class FileComments
return null; return null;
} }
// Asked of the column, not of the relation. client_context_id is
// cascadeOnDelete, but a user is soft-deleted, so the cascade
// never fires: the column goes on pointing at a row that is still
// there while the relation resolves to null. Branching on the
// relation therefore read "this is Alice's conversation" as "this
// has no conversation" — and a null context on a Clients comment
// is the branch every client on the file reads (see
// VisibleCommentScope's opening rule). A private reply became a
// circular, and canAssignClient below was skipped on the way.
if ($replyTo->client_context_id === null) {
return null;
}
$client = $replyTo->clientContext; $client = $replyTo->clientContext;
if ($client === null) { if ($client === null) {
return null; // The column points at somebody, and that somebody is gone.
// There is nobody to answer, and the one outcome that must
// not follow from a filled column is the broadcast above, so
// this refuses rather than falling through to it.
throw new AuthorizationException('You cannot reply in this conversation.');
} }
if (! $this->library->canAssignClient($author, $client)) { if (! $this->library->canAssignClient($author, $client)) {
app/Modules/Comments/Http/Controllers/Api/CommentModerationController.php
+8 -7
View File
@@ -8,7 +8,7 @@ use App\Http\Controllers\Controller;
use App\Modules\Comments\FileComments; use App\Modules\Comments\FileComments;
use App\Modules\Comments\Http\Resources\Api\FileCommentResource; use App\Modules\Comments\Http\Resources\Api\FileCommentResource;
use App\Modules\Comments\Models\FileComment; use App\Modules\Comments\Models\FileComment;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\ViewableFileScope;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Http\Resources\Json\AnonymousResourceCollection; use Illuminate\Http\Resources\Json\AnonymousResourceCollection;
use Illuminate\Support\Facades\Gate; use Illuminate\Support\Facades\Gate;
@@ -30,16 +30,17 @@ class CommentModerationController extends Controller
{ {
public function __construct( public function __construct(
private readonly FileComments $comments, private readonly FileComments $comments,
private readonly StaffLibraryScope $library, private readonly ViewableFileScope $viewable,
) {} ) {}
/** /**
* List comments awaiting approval. * List comments awaiting approval.
* *
* Scoped by the same library boundary as everything else: a * Scoped by the same file boundary as everything else — the whole of
* client-scoped token sees pending comments only on files its owner * it, not just its library half: a client-scoped token sees pending
* could already open. Oldest first, so working through the list means * comments only on files its owner could already open, and a token
* working through the backlog. * whose owner holds no file key at all sees none. Oldest first, so
* working through the list means working through the backlog.
*/ */
public function index(Request $request): AnonymousResourceCollection public function index(Request $request): AnonymousResourceCollection
{ {
@@ -49,7 +50,7 @@ class CommentModerationController extends Controller
$pending = FileComment::query() $pending = FileComment::query()
->whereNull('approved_at') ->whereNull('approved_at')
->whereIn('file_id', $this->library->files($viewer)->select('id')) ->whereIn('file_id', $this->viewable->for($viewer)->select('id'))
->with(['author', 'clientContext']) ->with(['author', 'clientContext'])
->orderBy('created_at') ->orderBy('created_at')
->orderBy('id') ->orderBy('id')
app/Modules/Comments/Http/Controllers/CommentsController.php
+6 -4
View File
@@ -147,15 +147,17 @@ class CommentsController extends Controller
]; ];
} }
/**
* See CommentPresenter::authorType(): asked of the column, because
* that is what decides whether a comment is a guest's.
*/
private function authorType(FileComment $comment): string private function authorType(FileComment $comment): string
{ {
$author = $comment->author; if ($comment->isFromGuest()) {
if ($author === null) {
return 'guest'; return 'guest';
} }
return $author->isStaff() ? 'staff' : 'client'; return $comment->author?->isStaff() === true ? 'staff' : 'client';
} }
/** /**
app/Modules/Comments/Models/FileComment.php
+38 -5
View File
@@ -76,11 +76,30 @@ class FileComment extends Model
} }
/** /**
* The account that wrote this comment, deleted or not.
*
* `author_id` is cascadeOnDelete and the cascade never fires, because
* a user is soft-deleted: the row behind a deleted commenter is still
* there and the column still points at it. Handing back null for one
* left every caller to invent a meaning for the absence, and they
* invented different ones — the author type became "guest" on two
* screens and "client" in the API, while the name beside it stayed
* correct, and the author filter and the name search stopped matching
* the comment at all.
*
* Whether a comment is from a guest is decided by `author_id` alone.
* isFromGuest() and authorName() already say so; this makes the
* relation agree with them.
*
* Nothing that decides who may *read* a comment goes through here —
* VisibleCommentScope and FileCommentPolicy both compare `author_id`
* directly — so this widens no visibility.
*
* @return BelongsTo<User, $this> * @return BelongsTo<User, $this>
*/ */
public function author(): BelongsTo public function author(): BelongsTo
{ {
return $this->belongsTo(User::class, 'author_id'); return $this->belongsTo(User::class, 'author_id')->withTrashed();
} }
/** /**
@@ -113,18 +132,32 @@ class FileComment extends Model
* The name to show. Snapshotted for guests at write time; read live * The name to show. Snapshotted for guests at write time; read live
* for accounts so a rename is reflected everywhere at once. * for accounts so a rename is reflected everywhere at once.
* *
* author_id cascades on delete, so a row that has one always has the * A deleted account is still read. author_id cascades on delete, but
* account behind it — there is no deleted-author case to snapshot * a user is soft-deleted and the cascade never fires, so the row
* against, unlike the activity log's actor_name. * behind a deleted commenter is still there — and reading it through
* the plain relation returned null, which sent a named client's
* comment out as "Anonymous". That is what a guest comment looks
* like, and a guest comment is governed by different rules; the two
* must not be able to look the same. Whether the author is a guest is
* decided by author_id alone, which is also what isFromGuest() asks.
*/ */
public function authorName(): string public function authorName(): string
{ {
if ($this->author_id === null) {
return $this->guest_name ?? (string) __('Anonymous');
}
$author = $this->author; $author = $this->author;
if ($author !== null) { if ($author !== null) {
return $author->name; return $author->name;
} }
return $this->guest_name ?? (string) __('Anonymous'); // Trashed: the row is still there, the relation simply will not
// hand it over. Nothing comes back only once the grace-period
// erasure has removed the row for real.
$name = $this->author()->withTrashed()->value('name');
return is_string($name) ? $name : (string) __('Anonymous');
} }
} }
app/Modules/Files/Access/ClientIdentityScope.php
+227
View File
@@ -0,0 +1,227 @@
<?php
declare(strict_types=1);
namespace App\Modules\Files\Access;
use App\Models\User;
use App\Modules\Groups\Models\Group;
/**
* Whether a viewer may be told who a client is.
*
* A different question from whether they may read a file, and the gap
* between the two is the whole reason this exists. A stranger client's
* upload can sit legitimately inside a client-scoped staff member's
* library — shared with a group one of their own clients belongs to, or
* assigned to one of their clients alongside somebody else's. The file is
* theirs to read. The other client's name is not theirs to see.
*
* Commit 12a8ebe3 said exactly that while fixing one dashboard widget, and
* then the rule stayed in that widget. Every other place that serialises a
* file went on publishing the uploader and each recipient by name, so a
* manager assigned to one client could read the names and ids of clients
* on nobody's roster but their own out of ordinary file metadata. That is
* what this class ends: one statement of the rule, asked by every surface
* that names a client.
*
* Two things it deliberately is not:
*
* - It is not a download check. The file boundary is StaffLibraryScope's
* and FilePolicy's, and it is already correct — a file belonging only
* to a client off the roster is a 403 today. This narrows what a
* permitted response is allowed to say, nothing more.
* - It is not applied to staff. A colleague's name is not a client
* identity, and hiding it would hide who uploaded most of the library
* from the people who work in it.
*
* Unscoped staff are unaffected: they may identify everyone, which is what
* `null` means everywhere StaffLibraryScope answers this shape of question.
*/
class ClientIdentityScope
{
/**
* Memoised per viewer, since the listings ask once per row and each
* miss is a roster query. Registered as `scoped`, so this lasts a
* request and is dropped between queue jobs — the same lifetime, and
* for the same reason, as StaffLibraryScope's own memo.
*
* @var array<int, list<int>|null>
*/
private array $clientIds = [];
/** @var array<int, list<int>|null> */
private array $groupIds = [];
public function __construct(private readonly StaffLibraryScope $scope) {}
/**
* Whether $viewer may be told that $subject exists, and what they are
* called.
*
* A null subject is permitted: there is no identity to leak, and every
* caller here is reading an optional relation.
*/
public function permits(?User $viewer, ?User $subject): bool
{
if ($subject === null) {
return true;
}
if (! $subject->isClient()) {
return true;
}
if ($viewer === null) {
return false;
}
if ($viewer->is($subject)) {
return true;
}
$ids = $this->identifiableClientIds($viewer);
return $ids === null || in_array($subject->id, $ids, true);
}
/**
* The same question about a client known only by id — used where a
* caller has a foreign key rather than a loaded model.
*
* An id that belongs to nobody, or to a staff member, is permitted:
* there is no client identity behind it to protect.
*/
public function permitsClientId(?User $viewer, ?int $id): bool
{
if ($id === null) {
return true;
}
return $this->permits($viewer, User::query()->find($id));
}
/**
* Whether $viewer may be told a group exists.
*
* A group is a list of clients wearing one name, so naming one to
* somebody who may reach none of its members says the same thing
* naming a client would. The set is StaffLibraryScope's
* assignableGroupIds — every group holding at least one of the
* viewer's own clients.
*/
public function permitsGroupId(?User $viewer, ?int $id): bool
{
if ($id === null) {
return true;
}
if ($viewer === null) {
return false;
}
$ids = $this->identifiableGroupIds($viewer);
return $ids === null || in_array($id, $ids, true);
}
/**
* A client's name, or null when this viewer may not be told it.
*
* Null rather than a placeholder on purpose: every consumer of these
* fields already renders "no uploader recorded" for a null, because a
* deleted account leaves one behind. Inventing a "Hidden" string would
* be a new thing for sixteen locales to translate and would itself
* announce that there is somebody there to hide.
*/
public function nameOf(?User $viewer, ?User $subject): ?string
{
return $this->permits($viewer, $subject) ? $subject?->name : null;
}
/**
* Drop the entries this viewer may not be told about from a list of
* id/name pairs describing clients.
*
* @param list<array{id: int, name: string}> $pairs
* @return list<array{id: int, name: string}>
*/
public function filterClientPairs(?User $viewer, array $pairs): array
{
if ($this->identifiableClientIds($viewer) === null) {
return $pairs;
}
return array_values(array_filter(
$pairs,
fn (array $pair): bool => $this->permitsClientId($viewer, $pair['id']),
));
}
/**
* @param list<array{id: int, name: string}> $pairs
* @return list<array{id: int, name: string}>
*/
public function filterGroupPairs(?User $viewer, array $pairs): array
{
if ($this->identifiableGroupIds($viewer) === null) {
return $pairs;
}
return array_values(array_filter(
$pairs,
fn (array $pair): bool => $this->permitsGroupId($viewer, $pair['id']),
));
}
/**
* Both halves of a `shares` payload at once, since the two lists are
* always filtered together.
*
* @param array{clients: list<array{id: int, name: string}>, groups: list<array{id: int, name: string}>} $shares
* @return array{clients: list<array{id: int, name: string}>, groups: list<array{id: int, name: string}>}
*/
public function filterShares(?User $viewer, array $shares): array
{
return [
'clients' => $this->filterClientPairs($viewer, $shares['clients']),
'groups' => $this->filterGroupPairs($viewer, $shares['groups']),
];
}
/**
* Whether this viewer is narrowed at all. Callers use it to skip
* per-row work for the common unscoped case.
*/
public function isNarrowed(?User $viewer): bool
{
return $viewer === null || $this->identifiableClientIds($viewer) !== null;
}
/**
* @return list<int>|null
*/
private function identifiableClientIds(?User $viewer): ?array
{
if ($viewer === null) {
return [];
}
// Deliberately the same set as "who may I share with". A client on
// the roster is one this viewer already works with by name; a
// client off it is one they have no business knowing exists.
return $this->clientIds[$viewer->id] ??= $this->scope->assignableClientIds($viewer);
}
/**
* @return list<int>|null
*/
private function identifiableGroupIds(?User $viewer): ?array
{
if ($viewer === null) {
return [];
}
return $this->groupIds[$viewer->id] ??= $this->scope->assignableGroupIds($viewer);
}
}
app/Modules/Files/Access/OwnFileDownloads.php
+90
View File
@@ -0,0 +1,90 @@
<?php
declare(strict_types=1);
namespace App\Modules\Files\Access;
use App\Models\User;
use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLog;
use App\Modules\Files\Models\File;
use Illuminate\Support\Carbon;
use Illuminate\Support\Collection;
/**
* How often a client's own file has been taken, and when it last was.
*
* The question somebody asks about a file they sent: did it arrive? On a
* hosted free account the link is the whole of the sharing, so "3
* downloads, last one on Tuesday" is the only evidence there is that it
* worked.
*
* **Own files only, and that is a privacy rule rather than a scoping
* convenience.** A download entry says somebody fetched the file, and on
* a file shared with several clients, telling one of them the count tells
* them about the others' activity. Nobody is entitled to that except the
* person who put the file there. So a file shared *with* this client
* carries no numbers at all — not zero, which would be a claim, but
* nothing.
*
* Counts come from the activity log through File::downloads(), the same
* source every other download count in the interface uses. There is
* deliberately no counter column — see DownloadAllowance for the whole
* argument, which applies unchanged here.
*
* One query for a page, whatever it holds.
*/
class OwnFileDownloads
{
/**
* @param Collection<int, File> $files
* @return array<int, array{count: int, last_at: string|null}> keyed by
* file id, only for files this client uploaded
*/
public function forMany(Collection $files, User $client): array
{
$own = $files
->filter(fn (File $file): bool => $file->uploaded_by === $client->id)
->pluck('id')
->map(fn ($id): int => (int) $id)
->all();
if ($own === []) {
return [];
}
// Every own file gets an entry, including the ones with nothing to
// report: the difference between "nobody has downloaded this" and
// "this is not yours to know" is exactly what the caller renders,
// and a missing key would collapse the two.
$stats = [];
foreach ($own as $id) {
$stats[$id] = ['count' => 0, 'last_at' => null];
}
$rows = ActivityLog::query()
->selectRaw('subject_id, count(*) as downloads, max(created_at) as last_at')
->where('subject_type', (new File)->getMorphClass())
->whereIn('subject_id', $own)
->whereIn('action', [
Action::FileDownloaded->value,
Action::ShareLinkDownloaded->value,
Action::PublicFileDownloaded->value,
])
->groupBy('subject_id')
->get();
foreach ($rows as $row) {
$id = (int) $row->getAttribute('subject_id');
$lastAt = $row->getAttribute('last_at');
$stats[$id] = [
'count' => (int) $row->getAttribute('downloads'),
'last_at' => $lastAt === null ? null : Carbon::parse((string) $lastAt)->toIso8601String(),
];
}
return $stats;
}
}
app/Modules/Files/Access/ShareTargets.php
+30 -2
View File
@@ -28,13 +28,25 @@ use Illuminate\Support\Collection;
*/ */
class ShareTargets class ShareTargets
{ {
public function __construct(private readonly StaffLibraryScope $scope) {} public function __construct(
private readonly StaffLibraryScope $scope,
private readonly ClientIdentityScope $identity,
) {}
/** /**
* The clients and groups a subject is already shared with, as id/name * The clients and groups a subject is already shared with, as id/name
* pairs. Neutral keys, so callers can nest it ('shares' on the details * pairs. Neutral keys, so callers can nest it ('shares' on the details
* panel) or flatten it (the edit pages' assigned_* props). * panel) or flatten it (the edit pages' assigned_* props).
* *
* **This is the unfiltered truth, and it is not what a screen should
* show.** Everyone a file is really in front of is the right answer for
* deciding something — VisibleCommentScope resolves notification
* recipients from it, and a recipient left out of that list is one who
* never hears about a message addressed to them. It is the wrong answer
* for telling somebody, because a client-scoped viewer may hold a file
* that is also shared with a client they have no business knowing
* exists. Anything rendering these names wants assignedFor() below.
*
* @return array{clients: list<array{id: int, name: string}>, groups: list<array{id: int, name: string}>} * @return array{clients: list<array{id: int, name: string}>, groups: list<array{id: int, name: string}>}
*/ */
public function assigned(File|Folder $subject): array public function assigned(File|Folder $subject): array
@@ -47,6 +59,17 @@ class ShareTargets
]; ];
} }
/**
* assigned(), narrowed to the recipients this viewer may be told
* about. The display half of the pair — see the warning above.
*
* @return array{clients: list<array{id: int, name: string}>, groups: list<array{id: int, name: string}>}
*/
public function assignedFor(File|Folder $subject, ?User $viewer): array
{
return $this->identity->filterShares($viewer, $this->assigned($subject));
}
/** /**
* The assigned lists plus everything still available to share with, * The assigned lists plus everything still available to share with,
* narrowed to what this viewer is allowed to reach. * narrowed to what this viewer is allowed to reach.
@@ -76,7 +99,12 @@ class ShareTargets
->orderBy('name') ->orderBy('name')
->get(); ->get();
$assigned = $this->assigned($subject); // assignedFor, not assigned: an edit page listing a recipient this
// viewer may not identify would both name them and offer a control
// for a share the viewer cannot otherwise reach. available_* below
// was already narrowed this way; assigned_* was not, which is the
// asymmetry that made the whole panel a roster listing.
$assigned = $this->assignedFor($subject, $viewer);
return [ return [
'assigned_clients' => $assigned['clients'], 'assigned_clients' => $assigned['clients'],
app/Modules/Files/Access/StaffLibraryScope.php
+132 -9
View File
@@ -159,15 +159,37 @@ class StaffLibraryScope
return null; return null;
} }
$clientIds = $this->assignableClientIds($user) ?? []; return array_values($this->groups($user)->pluck('id')->map(fn ($id): int => (int) $id)->all());
}
if ($clientIds === []) { /**
return []; * Every group this staff member may be told about, as a query.
*
* The listing half of assignableGroupIds(), and the same rule: a
* group counts as theirs because one of their clients is in it. The
* two were not the same code, and the listing simply had none — so
* `/groups` and `/api/v1/groups` showed a scoped staff member every
* group on the installation, name, description and member count,
* including groups whose every member was somebody else's client
* (GHSA-r3hg-3fxw-rcmr).
*
* Deliberately the *sharing* rule rather than the change rule below.
* A scoped staff member may already share a file with a mixed group,
* so its existence is not news to them; what they may not do is
* rename, publish or delete it.
*
* @return Builder<Group>
*/
public function groups(User $user): Builder
{
$query = Group::query();
$clientIds = $this->assignableClientIds($user);
if ($clientIds === null) {
return $query;
} }
return array_values(Group::query() return $query->whereHas('members', fn (Builder $members) => $members->whereIn('users.id', $clientIds));
->whereHas('members', fn (Builder $members) => $members->whereIn('users.id', $clientIds))
->pluck('id')->map(fn ($id): int => (int) $id)->all());
} }
public function canAssignClient(User $user, User $client): bool public function canAssignClient(User $user, User $client): bool
@@ -249,7 +271,53 @@ class StaffLibraryScope
*/ */
public function allowsGroupChange(User $user, Group $group): bool public function allowsGroupChange(User $user, Group $group): bool
{ {
return $this->groupReachesNoFurther($user, $group); return $this->groupIsNotWhollySomebodyElses($user, $group)
&& $this->groupReachesNoFurther($user, $group);
}
/**
* Whether this group is somebody else's entirely — every member
* outside the staff member's roster, and none of theirs in it.
*
* The half allowsGroupChange() was missing. Reach answers "what would
* this group hand somebody", which is the right question for putting a
* client *into* it; it says nothing about who is already there. So a
* group with nothing shared with it yet passed the reach check
* vacuously, and a scoped staff member could rename it, delete it, or
* publish it — a group made entirely of clients they had never been
* assigned (GHSA-r3hg-3fxw-rcmr).
*
* **Not "every member is mine", which is the obvious reading and is
* wrong.** A mixed group has to stay changeable: GHSA-whmp-p9hv-r7j7
* settled that a scoped staff member opens such a group's edit screen
* and is shown only their own clients in it, rather than being refused
* the screen. Requiring every member to be theirs turns that narrowing
* back into a 404 and undoes the earlier fix. What is left over — a
* mixed group whose shared content reaches past their library — is
* refused by groupReachesNoFurther() beside this, which is the check
* that has always covered it.
*
* **And deliberately not folded into groupReachesNoFurther() either.**
* That predicate is shared with allowsGroupMembership(), where a group
* nobody has joined must stay usable so its creator can put the first
* member in — the case that method's own docblock calls out.
*
* An empty group is nobody else's, so whoever just made it can still
* name it.
*/
private function groupIsNotWhollySomebodyElses(User $user, Group $group): bool
{
$clientIds = $this->assignableClientIds($user);
if ($clientIds === null) {
return true;
}
if (! $group->members()->exists()) {
return true;
}
return $group->members()->whereIn('users.id', $clientIds)->exists();
} }
/** /**
@@ -268,6 +336,15 @@ class StaffLibraryScope
* row rather than from the assignment ignores the dead ones by * row rather than from the assignment ignores the dead ones by
* construction, which is also the right answer: a deleted file is * construction, which is also the right answer: a deleted file is
* not reach, because nobody can reach it. * not reach, because nobody can reach it.
*
* An expired file is the same answer for the same reason. Membership
* in this group grants nobody access to it — File::scopeVisibleToClient
* ends in notExpired(), so it is gone from every member's /my-files and
* the download is refused — while its absence from files() otherwise
* reads as "outside my library" and locks the group exactly as a
* deleted file used to. Expiry is reversible where deletion is not, so
* the file counts as reach again the moment it does: this asks what is
* reachable now, at the moment somebody is added or removed.
*/ */
private function groupReachesNoFurther(User $user, Group $group): bool private function groupReachesNoFurther(User $user, Group $group): bool
{ {
@@ -282,6 +359,7 @@ class StaffLibraryScope
$outside = File::query() $outside = File::query()
->whereIn('id', $assignedFiles) ->whereIn('id', $assignedFiles)
->notExpired()
->whereNotIn('id', $this->files($user)->select('id')) ->whereNotIn('id', $this->files($user)->select('id'))
->exists(); ->exists();
@@ -292,9 +370,54 @@ class StaffLibraryScope
$assignedFolders = FolderAssignment::query()->select('folder_id') $assignedFolders = FolderAssignment::query()->select('folder_id')
->where('assignable_type', $morph)->where('assignable_id', $group->id); ->where('assignable_type', $morph)->where('assignable_id', $group->id);
return ! Folder::query() // The whole subtree, not the folder the assignment names. A folder
->whereIn('id', $assignedFolders) // shared with a group hands its members everything inside it —
// File::scopeVisibleToClient matches on folder placement, and a
// folder is visible to a client when it or an ancestor is shared
// with them — so "is anything shared with this group outside my
// library" has to ask about the contents, which is what the
// docblock above already claims ("the folders whose subtrees it
// can browse").
//
// Measured: a scoped staff member's own folder, with a subfolder
// somebody else created inside it and somebody else's file in
// that. The folder is theirs, its contents are not, and adding
// their own client to a group holding the parent handed that
// client the file — which then enters the staff member's own
// library too, because files() is "everything my clients can
// see". That is the widening this guard exists to refuse, and the
// test above it says so in as many words.
$reachable = Folder::query()->whereIn('id', $assignedFolders)->get()
->flatMap(fn (Folder $folder): array => $folder->subtreeFolderIds())
->unique()
->values()
->all();
if ($reachable === []) {
return true;
}
if (Folder::query()
->whereIn('id', $reachable)
->whereNotIn('id', $this->folders($user)->select('id')) ->whereNotIn('id', $this->folders($user)->select('id'))
->exists()
) {
return false;
}
// And the files sitting in them. A folder can be inside the
// library while a file in it is not: files() is own uploads plus
// what an assigned client may see, and neither covers somebody
// else's upload into a folder this staff member happens to own.
//
// notExpired() for the same reason the assignment half above skips
// deleted files: membership in this group grants nobody access to
// an expired file, because scopeVisibleToClient ends by excluding
// them, and something nobody can reach is not reach.
return ! File::query()
->whereIn('folder_id', $reachable)
->notExpired()
->whereNotIn('id', $this->files($user)->select('id'))
->exists(); ->exists();
} }
} }
app/Modules/Files/Access/ViewableFileScope.php
+16 -6
View File
@@ -40,15 +40,25 @@ class ViewableFileScope
return File::query()->visibleToClient($user); return File::query()->visibleToClient($user);
} }
// Mirrors FilePolicy::view()'s staff branch: the permission half is if (! $this->permitsAnyFile($user)) {
// a property of the viewer, not the row, so it either opens the
// whole scope or closes it entirely.
$permitted = $user->can('upload') || $user->can('edit_files') || $user->can('edit_others_files');
if (! $permitted) {
return File::query()->whereRaw('1 = 0'); return File::query()->whereRaw('1 = 0');
} }
return $this->scope->files($user); return $this->scope->files($user);
} }
/**
* Whether a staff member holds any of the three keys that open file
* reading at all — the permission half of FilePolicy::view()'s staff
* branch, named once because more than one module has to ask it.
*
* It is a property of the viewer rather than of a row, so it either
* opens the whole scope or closes it entirely. That is also why a
* query narrowed by StaffLibraryScope alone is only half the check:
* the library says *which* files, this says *whether any*.
*/
public function permitsAnyFile(User $user): bool
{
return $user->can('upload') || $user->can('edit_files') || $user->can('edit_others_files');
}
} }
app/Modules/Files/Delivery/DeliveryMethod.php
+55
View File
@@ -0,0 +1,55 @@
<?php
declare(strict_types=1);
namespace App\Modules\Files\Delivery;
/**
* How a file's bytes get from this server's disk to the visitor.
*
* Uploads live outside the web root, so every download passes through a
* permission check in PHP first. What differs is what happens after that
* check passes: PHP can read the file and write it out itself, or it can
* answer with an empty body and a header telling the web server to send
* the file instead.
*
* The header is the fast path and it is not portable — each server reads
* a different one, and a server reading none of them serves the empty
* body, which is how an installation ends up handing out 0-byte
* downloads while every other page works. ProjectSend v1 had this as a
* four-way setting with PHP as the default; v2 hard-coded nginx's
* spelling for its first releases, which is
* https://github.com/projectsend/projectsend/issues/1765.
*/
enum DeliveryMethod: string
{
/**
* nginx: `X-Accel-Redirect`, carrying a *URL path* that the
* `location /protected-files/` block maps back onto the storage
* directory. That block is marked `internal`, which is what stops a
* visitor requesting the path directly.
*/
case Nginx = 'nginx';
/**
* Apache with `mod_xsendfile`, and LiteSpeed, which reads the same
* header: `X-Sendfile`, carrying an *absolute filesystem path*.
*
* Never chosen automatically. The module also needs `XSendFilePath`
* to whitelist the storage directory, and there is no way to detect
* that from here — picking this on the strength of the module being
* loaded would trade one silent failure for another.
*/
case XSendFile = 'xsendfile';
/**
* PHP reads the file and streams it.
*
* Works on every server, and costs a worker process for the duration
* of each download — a handful of large concurrent downloads can
* occupy every worker while the CPU sits idle. That is why it is the
* fallback rather than the default, and why an installation using it
* says so on the dashboard rather than being quietly slow.
*/
case Php = 'php';
}
app/Modules/Files/Delivery/FileDelivery.php
+273
View File
@@ -0,0 +1,273 @@
<?php
declare(strict_types=1);
namespace App\Modules\Files\Delivery;
use Illuminate\Http\Request;
use Illuminate\Http\Response;
use Illuminate\Support\Facades\Storage;
use Symfony\Component\HttpFoundation\BinaryFileResponse;
/**
* Puts a file that lives on this server's local disk on the wire.
*
* The single place that knows how the bytes travel. Four routes used to
* decide that for themselves and all four hard-coded nginx's header, so
* an Apache or LiteSpeed installation served four different flavours of
* empty response — uploads worked, thumbnails were broken images, and
* downloads arrived as 0 bytes. Callers now say *what* to send and this
* decides *how*.
*
* It authorizes nothing. Every caller has already done that its own way
* — a policy, a share token, a public-listing check — and the path it
* passes is always derived from a row it just authorized, never from the
* request. That is load-bearing: `serve()` will send any file under the
* storage root, so a caller that passed user input would have built a
* file-disclosure bug. The root check below is the backstop, not the
* rule.
*
* ### Choosing the method
*
* `PROJECTSEND_FILE_DELIVERY` picks one explicitly. Left at `auto` — the
* default — nginx gets its own fast path and everything else gets PHP
* streaming.
*
* Auto deliberately never chooses `xsendfile`. Apache's `mod_xsendfile`
* needs `XSendFilePath` to whitelist the storage directory as well as
* being loaded, and nothing here can see whether it does; choosing it
* because the module is present would swap a silent failure anybody can
* diagnose from the dashboard for one nobody can. So it stays something
* an operator turns on having configured it.
*
* A value that is not a method falls back to auto rather than throwing.
* A typo in an environment variable should cost speed, not every
* download on the installation.
*/
class FileDelivery
{
/**
* The disk uploads live on. Named rather than injected because the
* whole class is about the local-disk case: a file on S3 never
* reaches here, it is a signed redirect from StoredFileResponse.
*/
private const DISK = 'files';
/** The internal nginx location that maps back onto the storage root. */
private const NGINX_LOCATION = '/protected-files/';
public function __construct(private readonly Request $request) {}
/**
* The method in force, and whether it was detected or stated.
*
* @return array{method: DeliveryMethod, detected: bool, observed: bool}
*/
public function resolve(): array
{
$configured = config('projectsend.file_delivery');
$explicit = is_string($configured) ? DeliveryMethod::tryFrom($configured) : null;
if ($explicit !== null) {
return ['method' => $explicit, 'detected' => false, 'observed' => true];
}
// Whether there was anything to detect *from*. detect() reads
// SERVER_SOFTWARE, which only exists inside a request — so a
// console process has nothing to look at and falls to the `php`
// default. That default is right for the console (no web server is
// handling this, so nothing could hand a file off), and wrong as a
// statement about the installation, which is how somebody reading
// it from `artisan tinker` will take it.
//
// Reported rather than papered over: a reader who runs
// `describe()` from a shell on a perfectly good nginx box was
// being told `php`, with `detected: true` vouching for it. That
// cost somebody an afternoon before it was recognised as an
// artefact of asking outside a request.
$observed = is_string($this->request->server('SERVER_SOFTWARE'));
return ['method' => $this->detect(), 'detected' => true, 'observed' => $observed];
}
public function method(): DeliveryMethod
{
return $this->resolve()['method'];
}
/**
* The same answer as a plain array, for a screen or a probe.
*
* Spelled out rather than leaning on a backed enum encoding itself,
* because this shape is read by the dashboard and by whatever watches
* the installation from outside, and neither should change meaning if
* the enum ever grows a JsonSerializable of its own.
*
* `observed` is false only outside an HTTP request, where nothing can
* be detected and `method` is a default rather than a finding. Both
* screens that read this run in a request, so they always see true;
* it exists for whoever asks from a console.
*
* @return array{method: string, detected: bool, observed: bool}
*/
public function describe(): array
{
$resolved = $this->resolve();
return [
'method' => $resolved['method']->value,
// True when nobody said which to use. The distinction matters
// to the reader: a detected `php` is an installation that
// could be faster, a stated one is somebody's decision.
'detected' => $resolved['detected'],
// And whether the detection had anything to work with.
'observed' => $resolved['observed'],
];
}
/**
* What the server says it is.
*
* `SERVER_SOFTWARE` is set by the web server itself through the
* FastCGI parameters, so it describes the process actually holding
* the connection to PHP. That is the right thing to ask: the header
* has to be understood by *that* server, not by whatever sits in
* front of it.
*
* The known-wrong case is nginx reverse-proxying Apache, which
* INSTALL.md offers as a way to keep an existing Apache. This reads
* Apache and picks PHP streaming, so downloads work and are slower
* than they need to be — the safe direction, and the reason the
* override exists.
*/
private function detect(): DeliveryMethod
{
$software = $this->request->server('SERVER_SOFTWARE');
$software = strtolower(is_string($software) ? $software : '');
return str_contains($software, 'nginx') ? DeliveryMethod::Nginx : DeliveryMethod::Php;
}
/**
* @param string $path disk-relative, and always derived from an
* already-authorized row — never from the request
* @param int|null $length when the caller already knows it; PHP
* streaming ignores it and measures the file
*/
public function serve(string $path, string $mimeType, string $disposition, ?int $length = null): Response|BinaryFileResponse
{
$this->assertRelative($path);
$headers = array_filter([
'Content-Type' => $mimeType,
'Content-Disposition' => $disposition,
'Content-Length' => $length === null ? null : (string) $length,
], static fn (?string $value): bool => $value !== null);
return match ($this->method()) {
DeliveryMethod::Nginx => response('', 200, [
'X-Accel-Redirect' => self::NGINX_LOCATION.$path,
...$headers,
]),
DeliveryMethod::XSendFile => response('', 200, [
// An absolute filesystem path, unlike nginx's URL path.
// Renaming the header without changing the value is the
// obvious way to "add Apache support" and produces a
// second broken install.
'X-Sendfile' => $this->absolutePathWithin($path),
...$headers,
]),
DeliveryMethod::Php => $this->stream($this->absolutePathWithin($path), $headers),
};
}
/**
* @param array<string, string> $headers
*/
private function stream(string $absolute, array $headers): BinaryFileResponse
{
// A large download can outlive max_execution_time, and the visitor
// sees a truncated file rather than an error. The web server is
// not holding this one open for us.
if (function_exists('set_time_limit')) {
@set_time_limit(0);
}
// BinaryFileResponse rather than a hand-written readfile loop: it
// answers Range requests, which is what makes seeking through a
// long video work. nginx does that for itself on the fast path, so
// rolling our own here would break preview scrubbing on exactly
// the installations this fallback exists for.
//
// Content-Length is deliberately dropped from the headers: the
// response sets its own from the file, and a caller's figure that
// disagrees — a stale `files.size`, or a range being served —
// truncates the download.
unset($headers['Content-Length']);
return new BinaryFileResponse($absolute, 200, $headers);
}
/**
* The path must stay a path *inside* the storage area.
*
* Checked for every method, and without touching the filesystem,
* because nginx resolves `..` in the URL it is handed just as
* happily as a filesystem call would -- and because every method
* puts this value into a response header. Callers pass paths from rows
* they authorized rather than from the request, so this is a
* backstop; it is here because the cost of being wrong about that,
* once, is handing over any file the web server can read.
*/
private function assertRelative(string $path): void
{
abort_if(
$path === ''
|| str_starts_with($path, '/')
|| preg_match('#(^|/)\.\.(/|$)#', $path) === 1
// A control character in the path is header injection, not
// traversal: this value is written into X-Accel-Redirect or
// X-Sendfile, and a CR or LF in a header value splits the
// response. PHP's header() refuses to emit one, so the real
// effect is a 500 on every download, preview and thumbnail
// of that file rather than a split -- a file permanently
// broken by its own name.
//
// Paths are `Y/m/{uuid}.{ext}` and generated here, so this
// should be unreachable. It is checked because the
// extension is not: it is taken from the uploader's
// filename, and on a migrated installation from a v1
// database, which is somebody else's data.
|| preg_match('/[\x00-\x1F\x7F]/', $path) === 1,
404,
);
}
/**
* The absolute path, proven to resolve inside the storage root.
*
* Only the two methods that hand over a *filesystem* path need this,
* and only they can afford it: it resolves symlinks, so it answers
* the question `assertRelative()` cannot — whether the file is really
* where the path says it is.
*
* It also requires the file to exist, which is why nginx does not go
* through it. On that path PHP never opens the file, and adding a
* stat to every download to discover something nginx is about to
* discover anyway would be a cost with no answer attached.
*/
private function absolutePathWithin(string $path): string
{
$disk = Storage::disk(self::DISK);
$absolute = realpath($disk->path($path));
$root = realpath($disk->path(''));
abort_if(
$absolute === false || $root === false || ! str_starts_with($absolute, rtrim($root, '/').'/'),
404,
);
return $absolute;
}
}
app/Modules/Files/Delivery/StoredFileResponse.php
+49 -18
View File
@@ -7,8 +7,8 @@ namespace App\Modules\Files\Delivery;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Support\ContentDisposition; use App\Support\ContentDisposition;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Response;
use Illuminate\Support\Facades\Storage; use Illuminate\Support\Facades\Storage;
use Symfony\Component\HttpFoundation\Response;
/** /**
* A stored file's own bytes, put on the wire for whichever disk it lives * A stored file's own bytes, put on the wire for whichever disk it lives
@@ -20,15 +20,33 @@ use Illuminate\Support\Facades\Storage;
* asking. The one thing it knows is the thing each caller kept getting * asking. The one thing it knows is the thing each caller kept getting
* wrong on its own: that `$file->disk` decides how the bytes travel. * wrong on its own: that `$file->disk` decides how the bytes travel.
* *
* Local disk: X-Accel-Redirect, so nginx streams the file and PHP never * Local disk: handed to FileDelivery, which decides whether the web
* touches the bytes. Anything else — S3, GCS and friends — gets a * server sends the bytes or PHP does. Anything else — S3, GCS and
* short-lived presigned URL carrying the disposition, which an object * friends — gets a short-lived presigned URL carrying the disposition,
* store ranges just as well. * which an object store ranges just as well.
* *
* That distinction matters most for inline(): a <video> seeking through * That distinction matters most for inline(): a <video> seeking through
* an hour of footage issues a long tail of Range requests, and nginx's * an hour of footage issues a long tail of Range requests. Every local
* static handler answers those with 206s on its own, dropping the * delivery method answers those — nginx's static handler on the fast
* Content-Length below in favour of the range it actually served. * path, BinaryFileResponse when PHP is streaming — each dropping the
* Content-Length passed here in favour of the range actually served.
*
* The two paths are not equally revocable, which is why the lifetimes
* below differ. Every local delivery method authorises one response and
* no more — nginx's X-Accel-Redirect, Apache's X-Sendfile, or PHP
* streaming the bytes itself: these bytes, now, to this request, and
* nothing that outlives it. A presigned URL is a bearer
* credential — whoever holds it can fetch the file without passing the
* caller's checks again, and it outlives them: a download cap that is
* spent in the meantime, an expires_at that falls in between, an
* assignment that is withdrawn. Nothing here can revoke one, so the only
* dial is how long it lasts.
*
* A download needs to survive being followed, which is a redirect and a
* request: a minute is generous. A preview is held by the player for as
* long as somebody watches, and each seek outside the buffer is a fresh
* Range request against the same URL, so it keeps the hour. That is the
* trade, stated rather than left in a single number.
* *
* Callers of inline() must have established that the mime type is * Callers of inline() must have established that the mime type is
* inline-safe first; PreviewKind is the allowlist, and the reason there * inline-safe first; PreviewKind is the allowlist, and the reason there
@@ -36,35 +54,48 @@ use Illuminate\Support\Facades\Storage;
*/ */
class StoredFileResponse class StoredFileResponse
{ {
/**
* Long enough for a browser, a download manager or a queued transfer
* to follow the redirect and start the request. An object store
* checks the signature when the request arrives, not while it runs,
* so a transfer that begins inside this window finishes however long
* it takes.
*/
private const DOWNLOAD_LINK_SECONDS = 60;
/**
* A preview is watched, not fetched: the player holds this URL and
* issues a Range request every time somebody seeks past the buffer,
* so it has to outlive the viewing rather than the redirect.
*/
private const PREVIEW_LINK_SECONDS = 3600;
public function __construct(private readonly FileDelivery $delivery) {}
/** Shown in place — a preview. */ /** Shown in place — a preview. */
public function inline(File $file): Response|RedirectResponse public function inline(File $file): Response|RedirectResponse
{ {
return $this->make($file, ContentDisposition::inline($file->original_name)); return $this->make($file, ContentDisposition::inline($file->original_name), self::PREVIEW_LINK_SECONDS);
} }
/** Handed over — a download. */ /** Handed over — a download. */
public function attachment(File $file): Response|RedirectResponse public function attachment(File $file): Response|RedirectResponse
{ {
return $this->make($file, ContentDisposition::attachment($file->original_name)); return $this->make($file, ContentDisposition::attachment($file->original_name), self::DOWNLOAD_LINK_SECONDS);
} }
private function make(File $file, string $disposition): Response|RedirectResponse private function make(File $file, string $disposition, int $linkSeconds): Response|RedirectResponse
{ {
if ($file->disk !== 'files') { if ($file->disk !== 'files') {
$url = Storage::disk($file->disk)->temporaryUrl( $url = Storage::disk($file->disk)->temporaryUrl(
$file->path, $file->path,
now()->addHour(), now()->addSeconds($linkSeconds),
['ResponseContentDisposition' => $disposition], ['ResponseContentDisposition' => $disposition],
); );
return redirect()->away($url); return redirect()->away($url);
} }
return response('', 200, [ return $this->delivery->serve($file->path, $file->mime_type, $disposition, $file->size);
'X-Accel-Redirect' => '/protected-files/'.$file->path,
'Content-Type' => $file->mime_type,
'Content-Disposition' => $disposition,
'Content-Length' => (string) $file->size,
]);
} }
} }
app/Modules/Files/Editing/ApplyFileEdits.php
+139
View File
@@ -0,0 +1,139 @@
<?php
declare(strict_types=1);
namespace App\Modules\Files\Editing;
use App\Models\User;
use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger;
use App\Modules\Comments\CommentingRules;
use App\Modules\Comments\CommentScope;
use App\Modules\Files\Models\File;
/**
* The one place that decides which fields an editor may actually write.
*
* Three surfaces edit a file — the staff editor, `/api/v1/files/{file}`,
* and now a client's own uploads in the portal — and they had grown two
* copies of the same eight permission checks with a third about to be
* written. The checks are not hard; the problem is that they are *easy*,
* so a new field gets added to one caller and the drift is invisible until
* somebody finds the surface where the gate is missing.
*
* The split is deliberate: **callers normalise, this gates.** A caller
* turns its own request shape into `$changes` — form semantics versus the
* API's `sometimes`, a date string versus an instant — and this decides
* what the actor is allowed to write, writes it, and records what happened.
*
* `$changes` uses array_key_exists semantics throughout: a key that is
* absent is left alone, a key present with `null` is written as null. That
* is the API's existing contract, and the web forms post every field they
* own, so it is also the forms'.
*
* Two things deliberately do NOT live here, because they are the caller's
* and getting them wrong is how a boundary breaks:
*
* - **Whether this actor may edit this file at all.** That is
* `Gate::authorize('update', $file)` and FilePolicy. Nothing below
* re-checks it.
* - **Whether a destination folder is reachable.** Staff ask
* StaffLibraryScope; a client asks `Folder::uploadableBy()`. Those are
* different questions with the same shape, and the staff one answers
* `true` for any client — see FilePolicy::update()'s note.
*/
class ApplyFileEdits
{
public function __construct(
private readonly ActivityLogger $activity,
private readonly CommentingRules $commenting,
) {}
/**
* @param array<string, mixed> $changes only the fields the caller
* wants written; absent keys
* are left as they are
*/
public function apply(User $actor, File $file, array $changes): void
{
$attributes = [];
// Covered by the permission to edit the file at all, which the
// policy has already settled by the time anything reaches here.
foreach (['name', 'description', 'folder_id'] as $field) {
if (array_key_exists($field, $changes)) {
$attributes[$field] = $changes[$field];
}
}
// Only meaningful while the comment scope is `selected`, and only
// offered by a form then — but a request reaching here directly
// must not be able to set a flag the UI is currently hiding.
if (array_key_exists('commentable', $changes) && $this->commenting->scope() === CommentScope::SelectedFiles) {
$attributes['commentable'] = $changes['commentable'];
}
// From here down, every field has a permission of its own, and the
// rule for all of them is the same: lacking it leaves the field
// exactly as it was rather than failing the request. An editor who
// may rename a file but not publish it saves a rename, and the
// public state does not move. The web and the API have always
// behaved this way; it is why the portal can reuse both forms.
if (array_key_exists('expires_at', $changes) && $actor->can('set_file_expiration_date')) {
$attributes['expires_at'] = $changes['expires_at'];
}
if (array_key_exists('download_limit', $changes) && $actor->can('limit_downloads')) {
$attributes['download_limit'] = $changes['download_limit'];
}
if (array_key_exists('download_limit_scope', $changes) && $actor->can('limit_downloads')) {
$attributes['download_limit_scope'] = $changes['download_limit_scope'];
}
$wasPublic = $file->public;
if (array_key_exists('public', $changes) && $actor->can('upload_public')) {
$attributes['public'] = $changes['public'];
// A caller that offers the slug passes what was submitted; one
// that does not simply omits the key and gets a derived slug.
// The client portal is the second kind on purpose — an
// installation-wide unique slug chosen by a client is a name to
// squat and an existence oracle to probe, for no benefit over a
// slug made from the name they already chose.
//
// Omitting the slug on an update keeps the current one: it must
// not silently change just because the name did.
$submitted = is_string($changes['slug'] ?? null) ? trim($changes['slug']) : '';
$attributes['slug'] = $submitted !== ''
? $submitted
: ($file->slug ?: File::uniqueSlugFrom(
is_string($changes['name'] ?? null) ? $changes['name'] : $file->name,
$file->id,
));
}
$file->update($attributes);
// After the write, not inside it: categories are a relation, not a
// column. Gated by their own key, so an editor who may rename but
// not categorise leaves them untouched.
if (array_key_exists('categories', $changes) && $actor->can('set_file_categories')) {
$file->categories()->sync($changes['categories']);
}
$this->activity->log(Action::FileUpdated, subject: $file);
// Publishing and unpublishing are their own entries. A file
// becoming reachable without a login is not a detail of "file
// updated", and it is the line an audit is most likely to be read
// for.
if (! $wasPublic && $file->public) {
$this->activity->log(Action::FileMadePublic, subject: $file, context: ['slug' => $file->slug]);
} elseif ($wasPublic && ! $file->public) {
$this->activity->log(Action::FileMadePrivate, subject: $file);
}
}
}
app/Modules/Files/Editing/FileExpiry.php
+67
View File
@@ -0,0 +1,67 @@
<?php
declare(strict_types=1);
namespace App\Modules\Files\Editing;
use App\Models\User;
use App\Modules\Files\Models\File;
use App\Modules\Platform\Localization\LocalDay;
use App\Modules\Platform\Localization\TimezoneRegistry;
use Carbon\Carbon;
/**
* Reading and writing a file's expiry in the zone of whoever is looking.
*
* The stored value is an instant. What a person sets is a calendar day,
* and "the 12th" means the end of the 12th where *they* live — otherwise a
* file asked to expire on the 12th dies partway through the 11th for
* anyone west of Greenwich, and gives anyone east of it most of a day
* nobody promised.
*
* The two halves have to agree, which is the whole reason they sit
* together: a form is rendered with asShown() and posts the same string
* back untouched with every other edit, so a caller compares against
* asShown() to tell "the editor changed the date" from "the editor renamed
* the file and the date came along for the ride". Re-deriving on every
* save instead moves the expiry by the difference between two people's
* zones each time somebody edits anything.
*
* Was three private copies — the staff editor, the API, and now the client
* portal — of which the API's was the only one that could read a
* timestamp.
*/
class FileExpiry
{
public function __construct(
private readonly TimezoneRegistry $timezones,
) {}
/**
* The stored instant as the calendar day a form should show, in the
* viewer's zone. Null when the file never expires.
*/
public function asShown(File $file, ?User $viewer): ?string
{
return $file->expires_at?->copy()->setTimezone($this->timezones->resolve($viewer))->toDateString();
}
/**
* The instant a submitted value actually names.
*
* A bare `YYYY-MM-DD` is a calendar day and means the end of it where
* the setter is — what every date input posts. Anything carrying a
* time is an instant somebody named on purpose and is stored as it
* arrives: the API can express a moment, and a date input cannot.
*/
public function instant(?string $value, ?User $setter): ?Carbon
{
if ($value === null) {
return null;
}
return preg_match('/^\d{4}-\d{2}-\d{2}$/', $value) === 1
? LocalDay::end($value, $this->timezones->resolve($setter))
: Carbon::parse($value);
}
}
app/Modules/Files/Events/FileWasStored.php
+33
View File
@@ -0,0 +1,33 @@
<?php
declare(strict_types=1);
namespace App\Modules\Files\Events;
use App\Models\User;
use App\Modules\Files\Models\File;
/**
* A file's bytes are on a disk and its row exists.
*
* Dispatched from StoreUploadedFile, which every upload path goes through
* — the chunked flow that staff and clients share, and the synchronous
* POST beside it — so a listener sees every upload once and does not have
* to know which route produced it.
*
* A notification rather than a filter: nothing here is mutable and no
* listener can change what was stored. Anything that needs to influence
* the upload has to do so before the bytes land, which is what
* ResolvingUploadDisk is for.
*
* Fired after the row is created and before the caller has linked a
* version or answered the request, so a listener sees a complete File and
* can safely read it back.
*/
class FileWasStored
{
public function __construct(
public readonly File $file,
public readonly User $uploader,
) {}
}
app/Modules/Files/FileDiskCleanup.php
+27 -5
View File
@@ -24,15 +24,37 @@ class FileDiskCleanup
{ {
public function delete(File $file): void public function delete(File $file): void
{ {
try { $this->attempt($file, fn () => Storage::disk($file->disk)->delete($file->path));
Storage::disk($file->disk)->delete($file->path);
// Every rendition, for every audience — a deleted file's bytes // Every rendition, for every audience — a deleted file's bytes must
// must not survive on disk because whoever wrote the cleanup // not survive on disk because whoever wrote the cleanup only knew
// only knew about the one copy they had in mind. // about the one copy they had in mind.
//
// Attempted separately from the original above, not because the two
// are unrelated but because they are on different disks: renditions
// are always local, and Storage::disk() throws outright for a name
// with no configured driver — which is exactly the state the
// original's disk is in when this fails at all. Sharing one `try`
// meant a file whose source disk had been removed kept every cached
// copy of itself, and nothing looks for those again:
// OrphanFileScanner skips the rendition directories on purpose.
$this->attempt($file, function () use ($file): void {
foreach (ThumbnailGenerator::pathsFor($file->id, $file->mime_type) as $renditionPath) { foreach (ThumbnailGenerator::pathsFor($file->id, $file->mime_type) as $renditionPath) {
Storage::disk('files')->delete($renditionPath); Storage::disk('files')->delete($renditionPath);
} }
});
}
/**
* Deliberately tolerant, as the class docblock says: the warning is the
* whole report. Nothing else will find these bytes -- the row is
* soft-deleted, and OrphanFileScanner::knownPaths() counts a trashed
* row's path as claimed, so a scan never lists it.
*/
private function attempt(File $file, callable $work): void
{
try {
$work();
} catch (Throwable $exception) { } catch (Throwable $exception) {
Log::warning('Could not remove disk bytes for deleted file '.$file->id.': '.$exception->getMessage()); Log::warning('Could not remove disk bytes for deleted file '.$file->id.': '.$exception->getMessage());
} }
app/Modules/Files/FilePolicy.php
+31 -5
View File
@@ -11,9 +11,15 @@ use App\Modules\Files\Models\File;
/** /**
* Ownership rules as policy methods (brief §6.13): "own" versus * Ownership rules as policy methods (brief §6.13): "own" versus
* "others'" files map onto the v1 permission pairs. Clients may only * "others'" files map onto the v1 permission pairs. Clients may only
* view/download what is assigned to them, directly or via a group. For * view/download what is assigned to them, directly or via a group, and may
* client-scoped staff, every action is additionally gated by the * edit or delete only what they uploaded themselves. For client-scoped
* StaffLibraryScope, so direct access can't reach out-of-scope files. * 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 class FilePolicy
{ {
@@ -33,8 +39,25 @@ class FilePolicy
public function update(User $user, File $file): bool 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()) { if (! $user->isStaff()) {
return false; return $file->isOwnedBy($user) && $user->can('edit_files');
} }
$permitted = $file->isOwnedBy($user) ? $user->can('edit_files') : $user->can('edit_others_files'); $permitted = $file->isOwnedBy($user) ? $user->can('edit_files') : $user->can('edit_others_files');
@@ -72,8 +95,11 @@ class FilePolicy
public function delete(User $user, File $file): bool 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()) { if (! $user->isStaff()) {
return false; return $file->isOwnedBy($user) && $user->can('delete_files');
} }
$permitted = $file->isOwnedBy($user) ? $user->can('delete_files') : $user->can('delete_others_files'); $permitted = $file->isOwnedBy($user) ? $user->can('delete_files') : $user->can('delete_others_files');
app/Modules/Files/FilesServiceProvider.php
+5
View File
@@ -4,6 +4,7 @@ declare(strict_types=1);
namespace App\Modules\Files; namespace App\Modules\Files;
use App\Modules\Files\Access\ClientIdentityScope;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Files\Models\Folder; use App\Modules\Files\Models\Folder;
@@ -30,6 +31,10 @@ class FilesServiceProvider extends ServiceProvider
// reached twice. Scoped rather than a singleton so a long-lived // reached twice. Scoped rather than a singleton so a long-lived
// queue worker starts each job with an empty memo. // queue worker starts each job with an empty memo.
$this->app->scoped(StaffLibraryScope::class); $this->app->scoped(StaffLibraryScope::class);
// Same lifetime, same reason: the identity rule memoises a roster
// per viewer and the file listings ask it once per row.
$this->app->scoped(ClientIdentityScope::class);
} }
public function boot(): void public function boot(): void
app/Modules/Files/Http/Controllers/Api/FilesController.php
+60 -44
View File
@@ -10,11 +10,12 @@ use App\Modules\Api\Support\PollingQuery;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Clients\ClientStorageUsage; use App\Modules\Clients\ClientStorageUsage;
use App\Modules\Comments\CommentingRules; use App\Modules\Files\Access\ClientIdentityScope;
use App\Modules\Comments\CommentScope;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Files\Access\ViewableFileScope; use App\Modules\Files\Access\ViewableFileScope;
use App\Modules\Files\DownloadLimitScope; use App\Modules\Files\DownloadLimitScope;
use App\Modules\Files\Editing\ApplyFileEdits;
use App\Modules\Files\Editing\FileExpiry;
use App\Modules\Files\Http\Resources\Api\FileResource; use App\Modules\Files\Http\Resources\Api\FileResource;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Files\Models\Folder; use App\Modules\Files\Models\Folder;
@@ -57,8 +58,10 @@ class FilesController extends Controller
private readonly UploadExtensionPolicy $extensionPolicy, private readonly UploadExtensionPolicy $extensionPolicy,
private readonly ClientStorageUsage $storageUsage, private readonly ClientStorageUsage $storageUsage,
private readonly ActivityLogger $activity, private readonly ActivityLogger $activity,
private readonly CommentingRules $commenting,
private readonly StaffLibraryScope $scope, private readonly StaffLibraryScope $scope,
private readonly ClientIdentityScope $identity,
private readonly ApplyFileEdits $fileEdits,
private readonly FileExpiry $expiry,
) {} ) {}
/** /**
@@ -110,6 +113,17 @@ class FilesController extends Controller
} }
if (array_key_exists('uploaded_by', $filters) && $filters['uploaded_by'] !== null) { if (array_key_exists('uploaded_by', $filters) && $filters['uploaded_by'] !== null) {
// A filter is a question, and this one asks "did client N put
// anything into my library". Answered plainly it is an oracle:
// a client-scoped caller could walk the id space and learn
// which clients off their roster share files with clients on
// it, without ever reading a name. So an id this caller may
// not identify matches nothing — indistinguishable from a
// client who has uploaded nothing, which is the point.
if (! $this->identity->permitsClientId($user, (int) $filters['uploaded_by'])) {
$query->whereRaw('1 = 0');
}
$query->where('files.uploaded_by', $filters['uploaded_by']); $query->where('files.uploaded_by', $filters['uploaded_by']);
} }
@@ -130,9 +144,12 @@ class FilesController extends Controller
} }
// Expiry is a filter, not a default: staff see expired files in the // Expiry is a filter, not a default: staff see expired files in the
// UI too (that is how they notice and act on them). Only the client // UI too (that is how they notice and act on them). Dropping them
// branch of the visibility rules drops them, and it does so inside // is the client branch's rule, applied inside the visibility scopes
// ViewableFileScope where it belongs. // where it belongs — which is also why a client-scoped caller does
// not get their clients' expired files back here whatever this
// filter says: their library is built on that same branch. See
// File::isExpired.
if ($request->has('expired') && ($filters['expired'] ?? null) !== null) { if ($request->has('expired') && ($filters['expired'] ?? null) !== null) {
$request->boolean('expired') ? $query->expired() : $query->notExpired(); $request->boolean('expired') ? $query->expired() : $query->notExpired();
} }
@@ -263,6 +280,12 @@ class FilesController extends Controller
* without the matching permission leaves that field untouched rather * without the matching permission leaves that field untouched rather
* than failing the whole request, which mirrors the web interface. * than failing the whole request, which mirrors the web interface.
* *
* `expires_at` accepts either a calendar day (`2026-09-12`) or a full
* timestamp. A day means the end of that day in the caller's timezone,
* which is what the same value means on the web and what the file's
* own `expires_at` reads back as; a timestamp is taken as the instant
* it names.
*
* `commentable` only has an effect while the installation's comment * `commentable` only has an effect while the installation's comment
* setting is "only files marked as commentable"; under any other * setting is "only files marked as commentable"; under any other
* setting it is ignored, again rather than failing. * setting it is ignored, again rather than failing.
@@ -288,9 +311,12 @@ class FilesController extends Controller
'download_limit_scope' => ['sometimes', Rule::enum(DownloadLimitScope::class)], 'download_limit_scope' => ['sometimes', Rule::enum(DownloadLimitScope::class)],
]); ]);
// Reparenting through update() must respect the same library scope as // Reparenting through update() must respect the same two rules as
// the web move()/bulkUpdate() paths: the destination folder must be // the web move()/bulkUpdate() paths: the destination folder must be
// one this user can see. Only enforced when folder_id actually // one this user can see, and one they may put content into. A public
// destination publishes what lands in it, so the second question is
// the one `upload_public` exists to ask and store() above already
// asks (GHSA-rxf8-wh8v-jm9j). Only enforced when folder_id actually
// changes, so re-saving a file that already sits in an out-of-scope // changes, so re-saving a file that already sits in an out-of-scope
// folder (reachable via a direct client share) still works. The // folder (reachable via a direct client share) still works. The
// integer rule admits numeric strings, so cast before the strict // integer rule admits numeric strings, so cast before the strict
@@ -299,48 +325,38 @@ class FilesController extends Controller
$validated['folder_id'] = (int) $validated['folder_id']; $validated['folder_id'] = (int) $validated['folder_id'];
if ($validated['folder_id'] !== $file->folder_id) { if ($validated['folder_id'] !== $file->folder_id) {
$this->scope->folders($user)->findOrFail($validated['folder_id']); $destination = $this->scope->folders($user)->whereKey($validated['folder_id'])->firstOrFail();
abort_unless(Folder::uploadableBy($user, $destination), 403);
} }
} }
$attributes = array_intersect_key($validated, array_flip(['name', 'description', 'folder_id'])); // `sometimes` throughout the rules above means $validated already
// holds exactly the fields the caller sent, which is the same
// array_key_exists contract ApplyFileEdits reads — so the payload
// passes through almost untouched. Which of them this token's user
// may actually write is that class's decision, shared with the
// staff editor and the client portal.
$changes = array_intersect_key($validated, array_flip([
'name',
'description',
'folder_id',
'commentable',
'download_limit',
'download_limit_scope',
'public',
'slug',
'categories',
]));
if (array_key_exists('expires_at', $validated) && $user->can('set_file_expiration_date')) { // The one field that needs converting rather than passing along: a
$attributes['expires_at'] = $validated['expires_at']; // caller may send a calendar day or a full timestamp, and a day
// means the end of that day where the caller is.
if (array_key_exists('expires_at', $validated)) {
$changes['expires_at'] = $this->expiry->instant($validated['expires_at'], $user);
} }
if (array_key_exists('download_limit', $validated) && $user->can('limit_downloads')) { $this->fileEdits->apply($user, $file, $changes);
$attributes['download_limit'] = $validated['download_limit'];
}
if (array_key_exists('download_limit_scope', $validated) && $user->can('limit_downloads')) {
$attributes['download_limit_scope'] = $validated['download_limit_scope'];
}
if (array_key_exists('commentable', $validated) && $this->commenting->scope() === CommentScope::SelectedFiles) {
$attributes['commentable'] = $validated['commentable'];
}
$wasPublic = $file->public;
if (array_key_exists('public', $validated) && $user->can('upload_public')) {
$attributes['public'] = $validated['public'];
$attributes['slug'] = ($validated['slug'] ?? '') ?: ($file->slug ?: File::uniqueSlugFrom($validated['name'] ?? $file->name, $file->id));
}
$file->update($attributes);
if (array_key_exists('categories', $validated) && $user->can('set_file_categories')) {
$file->categories()->sync($validated['categories']);
}
$this->activity->log(Action::FileUpdated, subject: $file);
if (! $wasPublic && $file->public) {
$this->activity->log(Action::FileMadePublic, subject: $file, context: ['slug' => $file->slug]);
} elseif ($wasPublic && ! $file->public) {
$this->activity->log(Action::FileMadePrivate, subject: $file);
}
return new FileResource($file->fresh()?->load(['folder', 'uploader', 'categories']) ?? $file); return new FileResource($file->fresh()?->load(['folder', 'uploader', 'categories']) ?? $file);
} }
app/Modules/Files/Http/Controllers/ChunkedUploadsController.php
+117 -11
View File
@@ -26,6 +26,7 @@ use App\Modules\Platform\Settings\Setting;
use App\Modules\Platform\Settings\Settings; use App\Modules\Platform\Settings\Settings;
use App\Support\Rules; use App\Support\Rules;
use Illuminate\Auth\Access\AuthorizationException; use Illuminate\Auth\Access\AuthorizationException;
use Illuminate\Contracts\Cache\LockTimeoutException;
use Illuminate\Http\JsonResponse; use Illuminate\Http\JsonResponse;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request; use Illuminate\Http\Request;
@@ -91,14 +92,45 @@ class ChunkedUploadsController extends Controller
$folder = isset($validated['folder_id']) ? Folder::query()->whereKey($validated['folder_id'])->first() : null; $folder = isset($validated['folder_id']) ? Folder::query()->whereKey($validated['folder_id'])->first() : null;
abort_unless(Folder::uploadableBy($user, $folder), 403); abort_unless(Folder::uploadableBy($user, $folder), 403);
// One session per file, and a person uploads a handful at a time.
// A cap is here because nothing else counts sessions: for anyone
// without a quota to spend — staff, and clients on an installation
// that sets no quotas — the number of sessions is the only thing
// standing between a declared size and any multiple of it.
$openSessions = UploadSession::query()->where('user_id', $user->id)->count();
$maxOpen = max(1, (int) config('projectsend.uploads.max_open_sessions'));
if ($openSessions >= $maxOpen) {
throw ValidationException::withMessages([
'filename' => __('Too many uploads are already in progress. Finish or cancel one and try again.'),
]);
}
// The declared size here is client-supplied and unverified until // The declared size here is client-supplied and unverified until
// complete()'s real assembled byte count — re-checked there too. // complete()'s real assembled byte count — re-checked there too.
if ($user->isClient()) { if ($user->isClient()) {
$quotaBytes = $this->storageUsage->quotaBytes($user); $quotaBytes = $this->storageUsage->quotaBytes($user);
if ($quotaBytes > 0 && $this->storageUsage->usedBytes($user) + (int) $validated['size'] > $quotaBytes) { // Sessions already open count too, at the size they declared.
// A quota measured against stored files alone is spent twice
// over by opening the sessions one after another: each one is
// told there is room, because the ones before it had not
// finished and so had not become files. putPart() holds each
// session to its declaration, so reserving the declarations
// here is what puts bytes waiting on the temporary volume
// under the same ceiling as bytes that landed.
$pendingBytes = (int) UploadSession::query()->where('user_id', $user->id)->sum('size');
if ($quotaBytes > 0 && $this->storageUsage->usedBytes($user) + $pendingBytes + (int) $validated['size'] > $quotaBytes) {
throw ValidationException::withMessages([ throw ValidationException::withMessages([
'size' => __('This upload would exceed your storage quota of :quota MB.', ['quota' => (string) $user->storage_quota_mb]), 'size' => __('This upload would exceed your storage quota of :quota MB.', [
// The resolved quota, not the column: a client who
// was never given one of their own carries 0 there
// and inherits the site default, so printing the
// column reads "your storage quota of 0 MB" at the
// moment somebody is asking what their limit is.
'quota' => (string) $this->storageUsage->quotaMb($user),
]),
]); ]);
} }
} }
@@ -180,13 +212,7 @@ class ChunkedUploadsController extends Controller
// ownership of the session is still enforced below. // ownership of the session is still enforced below.
$this->authorizeSession($request, $session); $this->authorizeSession($request, $session);
// signPart() bounds the part number; bound the part body too, or a // signPart() bounds the part number; bound the part body too.
// session can absorb unlimited bytes. The quota is only enforceable
// at complete(), against the assembled size — until then nothing
// stops a client declaring a 1-byte upload and streaming gigabytes
// of parts, which never becomes a File row and so never counts
// against anything. Stale sessions are purged daily, so without a
// cap here the exposure is a day's worth of disk.
abort_unless($part >= 1 && $part <= 10000, 422); abort_unless($part >= 1 && $part <= 10000, 422);
$maxPartBytes = max(1, (int) config('projectsend.upload_part_size_mb')) * 1024 * 1024; $maxPartBytes = max(1, (int) config('projectsend.upload_part_size_mb')) * 1024 * 1024;
@@ -198,16 +224,48 @@ class ChunkedUploadsController extends Controller
abort(413); abort(413);
} }
// Bounding one request bounds one request, and nothing else. Ten
// thousand part numbers at twice a 20 MB part is about 400 GB per
// session, sessions were not counted against anything, and none of
// it becomes a File row — so a client with a 1 MB quota could
// declare a one-byte upload and fill the temporary volume, then do
// it again. The session needs a ceiling of its own, and the room
// for a part has to be claimed before the part is read: a body's
// length is not known until it has arrived, and by then it is on
// the disk this is protecting.
//
// The ceiling is the size the session declared, which store() has
// already weighed against the file-size limit and the quota. So
// what a part gets is whatever the session has left, and the write
// is then capped at exactly that — an over-long body is cut off
// mid-stream as it always was, just against a smaller number.
$reserve = $this->reservePartRoom($session, $part, $limit);
if ($reserve < 1) {
// 413 rather than 422: this is about the size of what is being
// sent, and a client's resume logic already understands it. The
// session survives — the parts it holds are untouched, and it
// can still be completed or aborted.
abort(413);
}
$stream = $request->getContent(true); $stream = $request->getContent(true);
try { try {
$etag = $this->parts->storePart($session, $part, $stream, $limit); $etag = $this->parts->storePart($session, $part, $stream, $reserve);
} catch (PartTooLargeException) { } catch (PartTooLargeException) {
abort(413); abort(413);
} finally { } finally {
if (is_resource($stream)) { if (is_resource($stream)) {
fclose($stream); fclose($stream);
} }
// In the finally, because every way out of here needs it: the
// refused part was deleted and weighs nothing, a client that
// hung up left a short one, and a clean write leaves exactly
// what it reserved. Without this a client's own retries would
// slowly exhaust a session that has plenty of room.
$session->settleStaged($reserve, $this->parts->partSize($session, $part));
} }
return response('', 200, [ return response('', 200, [
@@ -224,6 +282,52 @@ class ChunkedUploadsController extends Controller
]); ]);
} }
/**
* Claim room for one part, returning how many bytes were claimed — 0
* when the session has none left.
*
* Read-then-claim, under a lock held for the two statements and not
* for the transfer. The protocol sends parts in parallel and how many
* is the client's choice, so without it every part in flight reads the
* same "room left" and they all claim it; and making the claim alone
* atomic is no better, because then the honest parallel upload is the
* one that gets refused. The lock is the same per-session shape
* complete() already uses, and it is released before a byte is read.
*/
private function reservePartRoom(UploadSession $session, int $part, int $limit): int
{
$lock = Cache::lock('upload-part:'.$session->id, 30);
try {
$lock->block(15);
} catch (LockTimeoutException) {
// Nothing is wrong with the upload — the queue for this one
// session just did not clear. 503 with Retry-After is what the
// client's own backoff is for.
abort(503, headers: ['Retry-After' => '5']);
}
try {
$existing = $this->parts->partSize($session, $part);
$session->refresh();
// Re-sending a part replaces it rather than adding to it, so
// what it already holds is room this request may spend again.
// That is an ordinary resume.
$room = max(0, $session->size - ($session->staged_bytes - $existing));
$reserve = min($limit, $room);
if ($reserve > 0 && ! $session->reserveStaged($reserve, $existing)) {
return 0;
}
return $reserve;
} finally {
$lock->release();
}
}
/** /**
* List the parts already received, so an interrupted upload can resume * List the parts already received, so an interrupted upload can resume
* rather than start again. * rather than start again.
@@ -306,7 +410,9 @@ class ChunkedUploadsController extends Controller
$session->delete(); $session->delete();
throw ValidationException::withMessages([ throw ValidationException::withMessages([
'size' => __('This upload would exceed your storage quota of :quota MB.', ['quota' => (string) $user->storage_quota_mb]), 'size' => __('This upload would exceed your storage quota of :quota MB.', [
'quota' => (string) $this->storageUsage->quotaMb($user),
]),
]); ]);
} }
} }
app/Modules/Files/Http/Controllers/ClientFilesController.php
+7 -1
View File
@@ -6,6 +6,7 @@ namespace App\Modules\Files\Http\Controllers;
use App\Http\Controllers\Controller; use App\Http\Controllers\Controller;
use App\Models\User; use App\Models\User;
use App\Modules\Files\Access\ClientIdentityScope;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Files\Models\Category; use App\Modules\Files\Models\Category;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
@@ -28,6 +29,7 @@ class ClientFilesController extends Controller
{ {
public function __construct( public function __construct(
private readonly StaffLibraryScope $scope, private readonly StaffLibraryScope $scope,
private readonly ClientIdentityScope $identity,
) {} ) {}
public function index(Request $request, User $client): Response public function index(Request $request, User $client): Response
@@ -66,7 +68,11 @@ class ClientFilesController extends Controller
'size' => $file->size, 'size' => $file->size,
'created_at' => $file->created_at?->toIso8601String(), 'created_at' => $file->created_at?->toIso8601String(),
'uploaded_by_client' => $file->uploaded_by === $client->id, 'uploaded_by_client' => $file->uploaded_by === $client->id,
'uploader' => $file->uploader?->name, // Being allowed to browse this client's files does not
// extend to the other clients who shared files with them:
// a file reaches this listing through the client in the
// URL, and its uploader can be somebody else entirely.
'uploader' => $this->identity->nameOf($viewer, $file->uploader),
'downloads_count' => $file->downloads_count, 'downloads_count' => $file->downloads_count,
'can_download' => Gate::forUser($viewer)->allows('view', $file), 'can_download' => Gate::forUser($viewer)->allows('view', $file),
'categories' => $file->categories->map(fn (Category $category): array => [ 'categories' => $file->categories->map(fn (Category $category): array => [
app/Modules/Files/Http/Controllers/DownloadSettingsController.php
+10
View File
@@ -7,6 +7,7 @@ namespace App\Modules\Files\Http\Controllers;
use App\Http\Controllers\Controller; use App\Http\Controllers\Controller;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Delivery\FileDelivery;
use App\Modules\Platform\Settings\Setting; use App\Modules\Platform\Settings\Setting;
use App\Modules\Platform\Settings\Settings; use App\Modules\Platform\Settings\Settings;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
@@ -24,12 +25,21 @@ class DownloadSettingsController extends Controller
public function __construct( public function __construct(
private readonly Settings $settings, private readonly Settings $settings,
private readonly ActivityLogger $activity, private readonly ActivityLogger $activity,
private readonly FileDelivery $delivery,
) {} ) {}
public function edit(): Response public function edit(): Response
{ {
return Inertia::render('system/settings/downloads', [ return Inertia::render('system/settings/downloads', [
'max_zip_download_size_mb' => $this->settings->get(Setting::MaxZipDownloadSizeMb), 'max_zip_download_size_mb' => $this->settings->get(Setting::MaxZipDownloadSizeMb),
// Not a setting, and shown here because this is where somebody
// coming from v1 looks for one: v1 had a "Download method"
// dropdown on its uploads options screen. It is an environment
// variable now rather than a stored setting, because it
// describes the server the installation is running on rather
// than a preference — a value in the database can be restored
// onto a different server and be wrong there.
'file_delivery' => $this->delivery->describe(),
]); ]);
} }
app/Modules/Files/Http/Controllers/FileDetailsController.php
+9 -4
View File
@@ -11,6 +11,7 @@ use App\Modules\Audit\ActivityLog;
use App\Modules\Audit\ActivityPresenter; use App\Modules\Audit\ActivityPresenter;
use App\Modules\Audit\DownloadPresenter; use App\Modules\Audit\DownloadPresenter;
use App\Modules\Comments\CommentingRules; use App\Modules\Comments\CommentingRules;
use App\Modules\Files\Access\ClientIdentityScope;
use App\Modules\Files\Access\DownloadAllowance; use App\Modules\Files\Access\DownloadAllowance;
use App\Modules\Files\Access\ShareTargets; use App\Modules\Files\Access\ShareTargets;
use App\Modules\Files\DownloadLimitScope; use App\Modules\Files\DownloadLimitScope;
@@ -79,6 +80,7 @@ class FileDetailsController extends Controller
private readonly ActivityPresenter $presenter, private readonly ActivityPresenter $presenter,
private readonly DownloadPresenter $downloadPresenter, private readonly DownloadPresenter $downloadPresenter,
private readonly ShareTargets $shareTargets, private readonly ShareTargets $shareTargets,
private readonly ClientIdentityScope $identity,
private readonly CommentingRules $commenting, private readonly CommentingRules $commenting,
private readonly FileVersionLinks $versionLinks, private readonly FileVersionLinks $versionLinks,
private readonly DownloadAllowance $allowance, private readonly DownloadAllowance $allowance,
@@ -100,7 +102,10 @@ class FileDetailsController extends Controller
'size' => $file->size, 'size' => $file->size,
'mime_type' => $file->mime_type, 'mime_type' => $file->mime_type,
'checksum' => $file->checksum, 'checksum' => $file->checksum,
'uploader' => $file->uploader?->name, // Null when the uploader is a client this viewer may not
// be told about, which reads the same as an uploader whose
// account has since been deleted.
'uploader' => $this->identity->nameOf($viewer, $file->uploader),
'folder' => $file->folder?->only('id', 'name'), 'folder' => $file->folder?->only('id', 'name'),
'categories' => $file->categories()->orderBy('name')->get() 'categories' => $file->categories()->orderBy('name')->get()
->map(fn (Category $category): array => ['id' => $category->id, 'name' => $category->name, 'color' => $category->color]) ->map(fn (Category $category): array => ['id' => $category->id, 'name' => $category->name, 'color' => $category->color])
@@ -140,7 +145,7 @@ class FileDetailsController extends Controller
// Resolved from the chain root for a revision (ShareTargets // Resolved from the chain root for a revision (ShareTargets
// does that), so this names who really has the file. The panel // does that), so this names who really has the file. The panel
// says where those recipients are set. // says where those recipients are set.
'shares' => $this->shareTargets->assigned($file), 'shares' => $this->shareTargets->assignedFor($file, $viewer),
'sharing_root' => $file->isRevision() 'sharing_root' => $file->isRevision()
? File::query()->find($file->sharingOwnerId())?->only('id', 'name') ? File::query()->find($file->sharingOwnerId())?->only('id', 'name')
: null, : null,
@@ -368,7 +373,7 @@ class FileDetailsController extends Controller
'name' => $folder->name, 'name' => $folder->name,
'files_count' => $folder->files()->count(), 'files_count' => $folder->files()->count(),
'children_count' => $folder->children()->count(), 'children_count' => $folder->children()->count(),
'creator' => $folder->creator?->name, 'creator' => $this->identity->nameOf($viewer, $folder->creator),
'created_at' => $folder->created_at?->toIso8601String(), 'created_at' => $folder->created_at?->toIso8601String(),
'open_url' => route('files.index', ['folder' => $folder->id], false), 'open_url' => route('files.index', ['folder' => $folder->id], false),
// Read-only here, same as a file's shares — sharing (and every // Read-only here, same as a file's shares — sharing (and every
@@ -377,7 +382,7 @@ class FileDetailsController extends Controller
'edit_url' => route('folders.share', $folder, false), 'edit_url' => route('folders.share', $folder, false),
'can_update' => Gate::forUser($viewer)->allows('update', $folder), 'can_update' => Gate::forUser($viewer)->allows('update', $folder),
'can_view_activity' => $viewer->can('view_actions_log'), 'can_view_activity' => $viewer->can('view_actions_log'),
'shares' => $this->shareTargets->assigned($folder), 'shares' => $this->shareTargets->assignedFor($folder, $viewer),
]); ]);
} }
app/Modules/Files/Http/Controllers/FileDownloadController.php
+7 -6
View File
@@ -12,15 +12,16 @@ use App\Modules\Files\Delivery\StoredFileResponse;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Http\Response;
use Illuminate\Support\Facades\Gate; use Illuminate\Support\Facades\Gate;
use Symfony\Component\HttpFoundation\Response;
/** /**
* Authorized downloads without the bytes ever traversing PHP: the app * Authorized downloads: the app checks the policy, and StoredFileResponse
* checks the policy, and StoredFileResponse answers with either an * decides how the bytes travel — a presigned URL when the file lives on
* X-Accel-Redirect for nginx to stream from the protected location * external storage, and otherwise whichever local delivery method this
* (brief §3) or a presigned URL when the file lives on external storage, * installation's web server understands (see FileDelivery). On nginx that
* since nginx has no way to serve bytes it doesn't have on disk. * is an X-Accel-Redirect and the bytes never traverse PHP at all; on a
* server with no such header PHP streams them, which is slower and works.
*/ */
class FileDownloadController extends Controller class FileDownloadController extends Controller
{ {
app/Modules/Files/Http/Controllers/FileThumbnailController.php
+30 -36
View File
@@ -6,11 +6,12 @@ namespace App\Modules\Files\Http\Controllers;
use App\Http\Controllers\Controller; use App\Http\Controllers\Controller;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Access\DownloadAllowance; use App\Modules\Files\Access\DownloadAllowance;
use App\Modules\Files\Delivery\FileDelivery;
use App\Modules\Files\Delivery\StoredFileResponse; use App\Modules\Files\Delivery\StoredFileResponse;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Files\Preview\PreviewKind; use App\Modules\Files\Preview\PreviewKind;
use App\Modules\Files\Preview\PreviewLog;
use App\Modules\Files\Thumbnails\Events\ResolvingImageRendering; use App\Modules\Files\Thumbnails\Events\ResolvingImageRendering;
use App\Modules\Files\Thumbnails\ImageAudience; use App\Modules\Files\Thumbnails\ImageAudience;
use App\Modules\Files\Thumbnails\ImageRendition; use App\Modules\Files\Thumbnails\ImageRendition;
@@ -21,15 +22,14 @@ use App\Modules\Platform\Settings\Settings;
use App\Support\ContentDisposition; use App\Support\ContentDisposition;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Http\Response;
use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\Event; use Illuminate\Support\Facades\Event;
use Illuminate\Support\Facades\Gate; use Illuminate\Support\Facades\Gate;
use Illuminate\Support\Facades\Storage; use Illuminate\Support\Facades\Storage;
use Symfony\Component\HttpFoundation\Response;
/** /**
* Two inline (never `attachment`) views of a file, same X-Accel-Redirect * Two inline (never `attachment`) views of a file, delivered the same way
* pattern as FileDownloadController: a bounded thumbnail for listing rows, * FileDownloadController delivers one: a bounded thumbnail for listing rows,
* and a larger view opened in a new tab when a thumbnail is clicked. * and a larger view opened in a new tab when a thumbnail is clicked.
* `thumbnail()` stays unlogged — it fires automatically as an `<img src>` * `thumbnail()` stays unlogged — it fires automatically as an `<img src>`
* for every row on every listing render, not a deliberate action, and * for every row on every listing render, not a deliberate action, and
@@ -72,11 +72,12 @@ class FileThumbnailController extends Controller
{ {
public function __construct( public function __construct(
private readonly ThumbnailGenerator $thumbnails, private readonly ThumbnailGenerator $thumbnails,
private readonly ActivityLogger $activity, private readonly PreviewLog $previews,
private readonly DownloadAllowance $allowance, private readonly DownloadAllowance $allowance,
private readonly StoredFileResponse $bytes, private readonly StoredFileResponse $bytes,
private readonly LocalSourceFile $source, private readonly LocalSourceFile $source,
private readonly Settings $settings, private readonly Settings $settings,
private readonly FileDelivery $delivery,
) {} ) {}
public function thumbnail(Request $request, File $file): Response public function thumbnail(Request $request, File $file): Response
@@ -144,7 +145,10 @@ class FileThumbnailController extends Controller
// file. // file.
abort_unless($this->allowance->allows($file, $request->user()), 403); abort_unless($this->allowance->allows($file, $request->user()), 403);
$this->logPreview($file, $request); // Debounced, because a browser turns one video into dozens of
// Range requests — see PreviewLog, which the anonymous twin in
// PublicGroupsController::preview shares.
$this->previews->record(Action::FilePreviewed, $file, $request->user());
if ($kind === PreviewKind::Image) { if ($kind === PreviewKind::Image) {
$audience = ImageAudience::forViewer($request->user()); $audience = ImageAudience::forViewer($request->user());
@@ -164,29 +168,6 @@ class FileThumbnailController extends Controller
return $this->bytes->inline($file); return $this->bytes->inline($file);
} }
/**
* One log row per viewer per file per five minutes.
*
* Watching a video is a single deliberate act that the browser turns
* into dozens of Range requests against this route, and each one
* arrives here indistinguishable from someone clicking preview again.
* Cache::add is the whole mechanism: it writes only if the key is
* absent, so the first request through the window logs and the rest
* are silent, without a read-then-write race between two of them.
*
* Keyed by viewer, so one client's playback never suppresses another
* person's preview of the same file. Anonymous viewers do not reach
* this route at all — see PublicGroupsController::preview.
*/
private function logPreview(File $file, Request $request): void
{
$key = 'file-preview-logged:'.$file->id.':'.($request->user()->id ?? 'guest');
if (Cache::add($key, true, now()->addMinutes(5))) {
$this->activity->log(Action::FilePreviewed, subject: $file);
}
}
/** /**
* The cached rendition's path on the local disk, generating it first * The cached rendition's path on the local disk, generating it first
* if this is the first time anyone has asked for it. Null only when * if this is the first time anyone has asked for it. Null only when
@@ -202,8 +183,19 @@ class FileThumbnailController extends Controller
$disk = Storage::disk('files'); $disk = Storage::disk('files');
// Existence is the cache, and an empty file is not a rendition: it
// is what a render that died before writing anything leaves behind,
// and serving it hands the viewer a broken image for as long as the
// file lives — nothing invalidates a rendition once it is there.
// ThumbnailGenerator writes through a temporary file now, so this
// state can no longer be created here; it can still be inherited
// from an installation that ran an older version.
if ($disk->exists($path)) { if ($disk->exists($path)) {
return $path; if ($disk->size($path) > 0) {
return $path;
}
$disk->delete($path);
} }
$disk->makeDirectory(dirname($path)); $disk->makeDirectory(dirname($path));
@@ -221,10 +213,12 @@ class FileThumbnailController extends Controller
private function serve(File $file, string $path): Response private function serve(File $file, string $path): Response
{ {
return response('', 200, [ // No Content-Length: this is the rendition's size, not the
'X-Accel-Redirect' => '/protected-files/'.$path, // original file's, and $file->size is the wrong number for it.
'Content-Type' => $file->mime_type, return $this->delivery->serve(
'Content-Disposition' => ContentDisposition::inline($file->original_name), $path,
]); $file->mime_type,
ContentDisposition::inline($file->original_name),
);
} }
} }
app/Modules/Files/Http/Controllers/FilesController.php
+90 -87
View File
@@ -10,9 +10,12 @@ use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Comments\CommentingRules; use App\Modules\Comments\CommentingRules;
use App\Modules\Comments\CommentScope; use App\Modules\Comments\CommentScope;
use App\Modules\Files\Access\ClientIdentityScope;
use App\Modules\Files\Access\ShareTargets; use App\Modules\Files\Access\ShareTargets;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Files\DownloadLimitScope; use App\Modules\Files\DownloadLimitScope;
use App\Modules\Files\Editing\ApplyFileEdits;
use App\Modules\Files\Editing\FileExpiry;
use App\Modules\Files\Models\Category; use App\Modules\Files\Models\Category;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Files\Models\Folder; use App\Modules\Files\Models\Folder;
@@ -22,13 +25,10 @@ use App\Modules\Files\Uploads\StoreUploadedFile;
use App\Modules\Files\Uploads\UploadExtensionPolicy; use App\Modules\Files\Uploads\UploadExtensionPolicy;
use App\Modules\Files\Versions\FileVersionLinks; use App\Modules\Files\Versions\FileVersionLinks;
use App\Modules\Files\Versions\FileVersions; use App\Modules\Files\Versions\FileVersions;
use App\Modules\Platform\Localization\LocalDay;
use App\Modules\Platform\Localization\TimezoneRegistry;
use App\Modules\Platform\Settings\Setting; use App\Modules\Platform\Settings\Setting;
use App\Modules\Platform\Settings\Settings; use App\Modules\Platform\Settings\Settings;
use App\Support\PublicUrl; use App\Support\PublicUrl;
use App\Support\Rules; use App\Support\Rules;
use Carbon\Carbon;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Http\UploadedFile; use Illuminate\Http\UploadedFile;
@@ -49,10 +49,12 @@ class FilesController extends Controller
private readonly StaffLibraryScope $scope, private readonly StaffLibraryScope $scope,
private readonly PublicUrl $publicUrl, private readonly PublicUrl $publicUrl,
private readonly ShareTargets $shareTargets, private readonly ShareTargets $shareTargets,
private readonly ClientIdentityScope $identity,
private readonly CommentingRules $commenting, private readonly CommentingRules $commenting,
private readonly FileVersions $versions, private readonly FileVersions $versions,
private readonly FileVersionLinks $versionLinks, private readonly FileVersionLinks $versionLinks,
private readonly TimezoneRegistry $timezones, private readonly ApplyFileEdits $fileEdits,
private readonly FileExpiry $expiry,
) {} ) {}
public function create(Request $request): Response public function create(Request $request): Response
@@ -164,7 +166,7 @@ class FilesController extends Controller
'original_name' => $file->original_name, 'original_name' => $file->original_name,
'size' => $file->size, 'size' => $file->size,
'mime_type' => $file->mime_type, 'mime_type' => $file->mime_type,
'uploader' => $file->uploader?->name, 'uploader' => $this->identity->nameOf($viewer, $file->uploader),
'folder_id' => $file->folder_id, 'folder_id' => $file->folder_id,
'public' => $file->public, 'public' => $file->public,
'commentable' => $file->commentable, 'commentable' => $file->commentable,
@@ -173,7 +175,7 @@ class FilesController extends Controller
// calendar date the editor typed — read back in their // calendar date the editor typed — read back in their
// zone, not the server's, or a file set to expire on the // zone, not the server's, or a file set to expire on the
// 12th reopens showing the 11th. // 12th reopens showing the 11th.
'expires_at' => $file->expires_at?->copy()->setTimezone($this->timezones->resolve($request->user()))->toDateString(), 'expires_at' => $this->expiry->asShown($file, $request->user()),
'expired' => $file->isExpired(), 'expired' => $file->isExpired(),
'download_limit' => $file->download_limit, 'download_limit' => $file->download_limit,
'download_limit_scope' => ($file->download_limit_scope ?? DownloadLimitScope::Total)->value, 'download_limit_scope' => ($file->download_limit_scope ?? DownloadLimitScope::Total)->value,
@@ -274,6 +276,8 @@ class FilesController extends Controller
// change comparison below matches the model's int. // change comparison below matches the model's int.
$folderId = isset($validated['folder_id']) ? (int) $validated['folder_id'] : null; $folderId = isset($validated['folder_id']) ? (int) $validated['folder_id'] : null;
$user = $request->user(); $user = $request->user();
// Gate::authorize above cannot pass without one.
assert($user !== null);
// Reparenting through update() is the same privileged write as // Reparenting through update() is the same privileged write as
// move()/bulkUpdate(), so it needs the same guard: the destination // move()/bulkUpdate(), so it needs the same guard: the destination
@@ -281,68 +285,49 @@ class FilesController extends Controller
// folder actually changes, so re-saving a file that already sits in // folder actually changes, so re-saving a file that already sits in
// an out-of-scope folder (reachable via a direct client share) still // an out-of-scope folder (reachable via a direct client share) still
// works. // works.
if ($folderId !== null && $folderId !== $file->folder_id && $user !== null) { if ($folderId !== null && $folderId !== $file->folder_id) {
$this->scope->folders($user)->findOrFail($folderId); $destination = $this->scope->folders($user)->whereKey($folderId)->firstOrFail();
// And one they may publish into, if it is public. Reparenting
// through the edit form is the same privileged write as move().
abort_unless(Folder::uploadableBy($user, $destination), 403);
} }
$attributes = [ // Normalised into the shape ApplyFileEdits reads, then handed
// over: which of these the actor may actually write is that
// class's decision, and it is the same decision the API and the
// client portal get. See its docblock for why the split is here.
$changes = [
'name' => $validated['name'], 'name' => $validated['name'],
'description' => $validated['description'] ?? null, 'description' => $validated['description'] ?? null,
'folder_id' => $folderId, 'folder_id' => $folderId,
// Present unconditionally; the comment scope decides whether it
// is honoured. Defaulted to the stored value so a form that
// does not render the field cannot clear it.
'commentable' => $validated['commentable'] ?? $file->commentable,
'download_limit' => $validated['download_limit'] ?? null,
'download_limit_scope' => $validated['download_limit_scope'] ?? DownloadLimitScope::Total->value,
'public' => $validated['public'] ?? $file->public,
'slug' => $validated['slug'] ?? '',
'categories' => $validated['categories'] ?? [],
]; ];
// Only meaningful while the comment scope is `selected`, and only // The one field that is conditionally *present* rather than
// offered by the page then — but a request reaching here directly // conditionally honoured, and the reason it cannot move into
// must not be able to set a flag the UI is currently hiding, the // ApplyFileEdits: the form was rendered with the stored instant
// same shape as the upload_public gate below. // read back as a date in this viewer's zone, and posts it again
if ($this->commenting->scope() === CommentScope::SelectedFiles) { // untouched with every other edit. Re-deriving it unconditionally
$attributes['commentable'] = $validated['commentable'] ?? $file->commentable; // would move the expiry by the difference between two people's
// zones each time somebody merely renamed the file. Compared
// against the same string the form was given, so "unchanged" means
// what the editor actually saw.
$posted = $validated['expires_at'] ?? null;
if ($posted !== $this->expiry->asShown($file, $user)) {
$changes['expires_at'] = $this->expiry->instant($posted, $user);
} }
// Only a user who can set expiration dates may change this file's $this->fileEdits->apply($user, $file, $changes);
// own expiry — same "leave it alone if you lack the permission"
// rule as the upload_public gate below.
if ($request->user()?->can('set_file_expiration_date') === true) {
$attributes['expires_at'] = $this->expiryInstant($validated['expires_at'] ?? null, $request->user());
}
// Same rule again for the download cap, behind its own
// permission — the one that already gates a share link's
// max_downloads, since both are the same question asked about
// different objects.
if ($request->user()?->can('limit_downloads') === true) {
$attributes['download_limit'] = $validated['download_limit'] ?? null;
$attributes['download_limit_scope'] = $validated['download_limit_scope'] ?? DownloadLimitScope::Total->value;
}
$wasPublic = $file->public;
// Only a user who can manage public state may change it — a user
// who can edit a file but lacks upload_public leaves its public
// state exactly as it was, same rule as FoldersController::update.
if ($request->user()?->can('upload_public') === true) {
$attributes['public'] = $validated['public'] ?? $file->public;
// Omitting the field on an update leaves the current slug
// alone — it must not silently change just because the name
// did.
$attributes['slug'] = ($validated['slug'] ?? '') ?: ($file->slug ?: File::uniqueSlugFrom($validated['name'], $file->id));
}
$file->update($attributes);
// Categories are gated by their own permission; leave them untouched
// for a user who can edit the file but not set categories.
if ($request->user()?->can('set_file_categories') === true) {
$file->categories()->sync($validated['categories'] ?? []);
}
$this->activity->log(Action::FileUpdated, subject: $file);
if (! $wasPublic && $file->public) {
$this->activity->log(Action::FileMadePublic, subject: $file, context: ['slug' => $file->slug]);
} elseif ($wasPublic && ! $file->public) {
$this->activity->log(Action::FileMadePrivate, subject: $file);
}
return back()->with('success', __('File updated.')); return back()->with('success', __('File updated.'));
} }
@@ -363,9 +348,18 @@ class FilesController extends Controller
$folderId = $validated['folder_id'] ?? null; $folderId = $validated['folder_id'] ?? null;
$user = $request->user(); $user = $request->user();
// The target folder must be one the mover can actually see. // The target folder must be one the mover can actually see, and one
if ($folderId !== null && $user !== null) { // they are allowed to put content into. Those are two questions:
$this->scope->folders($user)->findOrFail($folderId); // a file in a public folder is published by being there, so the
// destination reaches the property `upload_public` guards without
// anybody touching the switch. Asking only the first let an editor
// who is deliberately not allowed to publish do it by dragging
// (GHSA-rxf8-wh8v-jm9j — the move half of GHSA-237r-jx85-j3hr,
// whose fix was wired into the upload paths and no further).
if ($folderId !== null && $user !== null && $folderId !== $file->folder_id) {
$destination = $this->scope->folders($user)->whereKey($folderId)->firstOrFail();
abort_unless(Folder::uploadableBy($user, $destination), 403);
} }
$file->update(['folder_id' => $folderId]); $file->update(['folder_id' => $folderId]);
@@ -422,13 +416,19 @@ class FilesController extends Controller
&& ($validated['remove_category_ids'] ?? []) === []; && ($validated['remove_category_ids'] ?? []) === [];
abort_if($touchesNothing, 422, __('Change at least one field before applying a bulk edit.')); abort_if($touchesNothing, 422, __('Change at least one field before applying a bulk edit.'));
// The target folder must be one this user can actually see — same // The target folder must be one this user can actually see, and one
// rule move() already applies to a single file's target. // they may put content into — the same two questions move() asks of
// a single file's target. Checked once, on the destination, rather
// than per file: the destination is one folder for the whole batch,
// and if putting content there publishes it then no file in the
// batch may go.
$targetFolderId = null; $targetFolderId = null;
if ($validated['folder_action'] === 'move') { if ($validated['folder_action'] === 'move') {
$targetFolderId = $validated['folder_id'] ?? null; $targetFolderId = $validated['folder_id'] ?? null;
if ($targetFolderId !== null) { if ($targetFolderId !== null) {
$this->scope->folders($user)->findOrFail($targetFolderId); $destination = $this->scope->folders($user)->whereKey($targetFolderId)->firstOrFail();
abort_unless(Folder::uploadableBy($user, $destination), 403);
} }
} }
@@ -463,7 +463,7 @@ class FilesController extends Controller
// update()'s expires_at handling. // update()'s expires_at handling.
if ($validated['expiration_action'] !== 'no_change' && $canSetExpiration) { if ($validated['expiration_action'] !== 'no_change' && $canSetExpiration) {
$attributes['expires_at'] = $validated['expiration_action'] === 'set' $attributes['expires_at'] = $validated['expiration_action'] === 'set'
? $this->expiryInstant($validated['expires_at'], $user) ? $this->expiry->instant($validated['expires_at'], $user)
: null; : null;
} }
@@ -504,9 +504,23 @@ class FilesController extends Controller
}); });
$requested = count($validated['file_ids']); $requested = count($validated['file_ids']);
$message = $updated < $requested
? __(':updated of :requested selected files were updated. The rest were skipped because you don\'t have permission to edit them.', ['updated' => $updated, 'requested' => $requested]) // Two different reasons a selected file can go unchanged, and they
: trans_choice(':count file updated.|:count files updated.', $updated, ['count' => $updated]); // are not the same sentence. Files dropped by the Gate::allows
// filter above are ones this user may not edit at all. A file that
// survived the filter and still changed nothing was editable --
// every field they asked to change was one their role does not let
// them set, which is the case the single-file editor states
// separately too. Reporting the first reason for the second told a
// staff member with edit_files but without set_file_expiration_date
// that three files they own are not theirs to edit.
$unreachable = $requested - $files->count();
$message = match (true) {
$updated === $requested => trans_choice(':count file updated.|:count files updated.', $updated, ['count' => $updated]),
$updated + $unreachable === $requested => __(':updated of :requested selected files were updated. The rest were skipped because you don\'t have permission to edit them.', ['updated' => $updated, 'requested' => $requested]),
default => __(':updated of :requested selected files were updated. The rest were skipped because you don\'t have permission to make those changes.', ['updated' => $updated, 'requested' => $requested]),
};
return back()->with('success', $message); return back()->with('success', $message);
} }
@@ -516,28 +530,17 @@ class FilesController extends Controller
Gate::authorize('delete', $file); Gate::authorize('delete', $file);
$name = $file->name; $name = $file->name;
// Soft delete; the bytes stay on disk until a purge policy // Soft delete of the row — but not of the bytes. File::booted()'s
// lands with the retention work. // `deleted` hook runs FileDiskCleanup on commit, so the upload and
// every cached rendition of it are gone from disk by the time this
// returns. The row is kept because version chains, the activity
// log and the erasure grace period all still point at it; nothing
// serves it (route-model binding 404s), and nothing ever
// forceDelete()s it either.
$file->delete(); $file->delete();
$this->activity->log(Action::FileDeleted, context: ['name' => $name]); $this->activity->log(Action::FileDeleted, context: ['name' => $name]);
return redirect()->route('files.index')->with('success', __('File deleted.')); return redirect()->route('files.index')->with('success', __('File deleted.'));
} }
/**
* The instant a `<input type="date">` expiry actually falls on.
*
* The form posts a bare `YYYY-MM-DD`, which Eloquent would otherwise
* store as midnight UTC — so "expires on the 12th" would cut the file
* off partway through the 11th for anyone in the Americas, and give
* anyone east of Greenwich most of a day they were not promised. It
* means the end of the 12th where the person setting it lives.
*/
private function expiryInstant(?string $date, ?User $setter): ?Carbon
{
return $date === null
? null
: LocalDay::end($date, $this->timezones->resolve($setter));
}
} }
app/Modules/Files/Http/Controllers/FoldersController.php
+88 -3
View File
@@ -10,6 +10,7 @@ use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Comments\Access\VisibleCommentScope; use App\Modules\Comments\Access\VisibleCommentScope;
use App\Modules\Comments\CommentingRules; use App\Modules\Comments\CommentingRules;
use App\Modules\Files\Access\ClientIdentityScope;
use App\Modules\Files\Access\DownloadAllowance; use App\Modules\Files\Access\DownloadAllowance;
use App\Modules\Files\Access\ShareTargets; use App\Modules\Files\Access\ShareTargets;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
@@ -54,6 +55,7 @@ class FoldersController extends Controller
private readonly ActivityLogger $activity, private readonly ActivityLogger $activity,
private readonly PublicUrl $publicUrl, private readonly PublicUrl $publicUrl,
private readonly ShareTargets $shareTargets, private readonly ShareTargets $shareTargets,
private readonly ClientIdentityScope $identity,
private readonly BreadcrumbBuilder $breadcrumbs, private readonly BreadcrumbBuilder $breadcrumbs,
private readonly CommentingRules $commenting, private readonly CommentingRules $commenting,
private readonly VisibleCommentScope $comments, private readonly VisibleCommentScope $comments,
@@ -240,7 +242,11 @@ class FoldersController extends Controller
'original_name' => $file->original_name, 'original_name' => $file->original_name,
'mime_type' => $file->mime_type, 'mime_type' => $file->mime_type,
'size' => $file->size, 'size' => $file->size,
'uploader' => $file->uploader ? [ // The whole block goes, not just the name: type and role
// describe the same person, and "a client uploaded this" on a
// row whose uploader is off this viewer's roster narrows who
// it could be just as effectively as naming them.
'uploader' => ($file->uploader !== null && $this->identity->permits($user, $file->uploader)) ? [
'name' => $file->uploader->name, 'name' => $file->uploader->name,
'type' => $file->uploader->type->value, 'type' => $file->uploader->type->value,
'role' => $file->uploader->role?->name, 'role' => $file->uploader->role?->name,
@@ -396,7 +402,20 @@ class FoldersController extends Controller
'parent_id' => Rules::folderId(), 'parent_id' => Rules::folderId(),
]); ]);
$newParent = $this->resolveParent($request->user(), $validated['parent_id'] ?? null); $user = $request->user();
$newParent = $this->resolveParent($user, $validated['parent_id'] ?? null);
// A folder carries its contents with it, and a folder inside a
// public one is public — isEffectivelyPublic() reads the whole
// ancestry. So dropping a private folder into a public parent
// publishes every file in its subtree at once, which is the same
// act the upload path refuses without `upload_public`. The flag on
// this screen is already guarded (update() above leaves public
// state alone without the permission); the placement was not
// (GHSA-rxf8-wh8v-jm9j).
if ($user !== null) {
abort_unless(Folder::uploadableBy($user, $newParent), 403);
}
$this->folders->move($folder, $newParent); $this->folders->move($folder, $newParent);
@@ -405,10 +424,32 @@ class FoldersController extends Controller
return back(); return back();
} }
public function destroy(Folder $folder): RedirectResponse public function destroy(Request $request, Folder $folder): RedirectResponse
{ {
Gate::authorize('delete', $folder); Gate::authorize('delete', $folder);
$viewer = $request->user();
assert($viewer !== null);
// Deleting a folder cascades to every file in its subtree, and a
// File's `deleted` hook removes the bytes from disk — there is no
// restore. Authorizing the folder is not authorizing its contents:
// FilePolicy::delete asks for `delete_others_files` on somebody
// else's upload, and for the library boundary on top of that, and
// neither question is asked anywhere on this path.
//
// MyFoldersController::destroy already refuses for the client half
// of the same cascade, in the same words. This is the staff half.
$blocked = $this->undeletableFileCount($viewer, $folder);
if ($blocked > 0) {
return back()->with('error', trans_choice(
'This folder cannot be deleted: it holds :count file you may not delete.|This folder cannot be deleted: it holds :count files you may not delete.',
$blocked,
['count' => (string) $blocked],
));
}
$name = $folder->name; $name = $folder->name;
$parentId = $folder->parent_id; $parentId = $folder->parent_id;
@@ -419,6 +460,50 @@ class FoldersController extends Controller
return redirect()->route('files.index', $parentId !== null ? ['folder' => $parentId] : [])->with('success', __('Folder deleted.')); return redirect()->route('files.index', $parentId !== null ? ['folder' => $parentId] : [])->with('success', __('Folder deleted.'));
} }
/**
* How many files in this folder's subtree the viewer may not delete.
*
* Asked as one count rather than FilePolicy::delete per file: a folder
* can hold thousands, Gate resolves a fresh policy for every check, and
* a per-row policy check on a listing is the cost 0a8b609e went to
* some trouble to remove. The two halves of FilePolicy::delete are
* expressible in SQL — the permission half is constant for this
* viewer, and the library half is the query StaffLibraryScope already
* memoises per request.
*
* Somebody holding both delete permissions and no library scope can
* delete anything in the subtree by construction, so they never pay for
* the query at all.
*/
private function undeletableFileCount(User $viewer, Folder $folder): int
{
$mayDeleteOwn = $viewer->can('delete_files');
$mayDeleteOthers = $viewer->can('delete_others_files');
$scoped = $viewer->isClientScoped();
if ($mayDeleteOwn && $mayDeleteOthers && ! $scoped) {
return 0;
}
return File::query()
->whereIn('folder_id', $folder->subtreeFolderIds())
->where(function (Builder $outer) use ($viewer, $mayDeleteOwn, $mayDeleteOthers, $scoped): void {
if (! $mayDeleteOwn) {
$outer->orWhere('uploaded_by', $viewer->id);
}
if (! $mayDeleteOthers) {
$outer->orWhere(fn (Builder $others): Builder => $others
->whereNull('uploaded_by')->orWhere('uploaded_by', '!=', $viewer->id));
}
if ($scoped) {
$outer->orWhereNotIn('id', $this->scope->files($viewer)->select('id'));
}
})
->count();
}
private function resolveParent(?User $user, ?int $parentId): ?Folder private function resolveParent(?User $user, ?int $parentId): ?Folder
{ {
if ($user === null || $parentId === null) { if ($user === null || $parentId === null) {
app/Modules/Files/Http/Controllers/MyFilesController.php
+242 -3
View File
@@ -5,14 +5,22 @@ declare(strict_types=1);
namespace App\Modules\Files\Http\Controllers; namespace App\Modules\Files\Http\Controllers;
use App\Http\Controllers\Controller; use App\Http\Controllers\Controller;
use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger;
use App\Modules\Clients\ClientStorageUsage; use App\Modules\Clients\ClientStorageUsage;
use App\Modules\Comments\Access\VisibleCommentScope; use App\Modules\Comments\Access\VisibleCommentScope;
use App\Modules\Comments\CommentingRules; use App\Modules\Comments\CommentingRules;
use App\Modules\Comments\CommentScope;
use App\Modules\Files\Access\DownloadAllowance; use App\Modules\Files\Access\DownloadAllowance;
use App\Modules\Files\Access\OwnFileDownloads;
use App\Modules\Files\DownloadLimitScope;
use App\Modules\Files\Editing\ApplyFileEdits;
use App\Modules\Files\Editing\FileExpiry;
use App\Modules\Files\Folders\BreadcrumbBuilder; use App\Modules\Files\Folders\BreadcrumbBuilder;
use App\Modules\Files\Models\Category; use App\Modules\Files\Models\Category;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Files\Models\Folder; use App\Modules\Files\Models\Folder;
use App\Modules\Files\Sharing\ClientShareLinks;
use App\Modules\Files\Uploads\UploadExtensionPolicy; use App\Modules\Files\Uploads\UploadExtensionPolicy;
use App\Modules\Files\Versions\FileVersionLinks; use App\Modules\Files\Versions\FileVersionLinks;
use App\Modules\Files\Versions\FileVersions; use App\Modules\Files\Versions\FileVersions;
@@ -22,6 +30,7 @@ use App\Modules\Platform\Settings\Settings;
use App\Modules\Platform\Theming\PublicThemeRegistry; use App\Modules\Platform\Theming\PublicThemeRegistry;
use App\Support\ConcatenatedPagination; use App\Support\ConcatenatedPagination;
use App\Support\Pagination; use App\Support\Pagination;
use App\Support\Rules;
use Illuminate\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Model;
use Illuminate\Http\JsonResponse; use Illuminate\Http\JsonResponse;
@@ -66,6 +75,11 @@ class MyFilesController extends Controller
private readonly DownloadAllowance $allowance, private readonly DownloadAllowance $allowance,
private readonly FileVersions $versions, private readonly FileVersions $versions,
private readonly FileVersionLinks $versionLinks, private readonly FileVersionLinks $versionLinks,
private readonly ClientShareLinks $shareLinks,
private readonly OwnFileDownloads $ownDownloads,
private readonly ApplyFileEdits $fileEdits,
private readonly FileExpiry $expiry,
private readonly ActivityLogger $activity,
) {} ) {}
public function index(Request $request): Response|RedirectResponse public function index(Request $request): Response|RedirectResponse
@@ -207,11 +221,21 @@ class MyFilesController extends Controller
$fileRows = $sliced['items']['files']; $fileRows = $sliced['items']['files'];
$commentCounts = $this->comments->countsFor($client, $fileRows); $commentCounts = $this->comments->countsFor($client, $fileRows);
// Two queries for the page, not two per row. No URL resolver: the // Two queries for the page, not two per row. Still no URL resolver:
// portal has no per-file page to link to, so a counterpart is named // the portal's per-file page is an *editor* for a client's own
// and not linked (see docs/theming-files-checklist.md). // uploads, and a version counterpart is frequently neither theirs
// nor editable — so a counterpart stays named and not linked (see
// docs/theming-files-checklist.md).
$versions = $this->versionLinks->forMany($fileRows, $client); $versions = $this->versionLinks->forMany($fileRows, $client);
$unreadComments = $this->comments->unreadCountsFor($client, array_values(array_map(intval(...), $fileRows->pluck('id')->all()))); $unreadComments = $this->comments->unreadCountsFor($client, array_values(array_map(intval(...), $fileRows->pluck('id')->all())));
// One query for the page. Already narrowed to links this client
// minted on files this client uploaded — see ClientShareLinks for
// why both halves are required.
$shareUrls = $this->shareLinks->forMany($fileRows, $client);
// Also one query for the page, and also own files only — see
// OwnFileDownloads for why telling a recipient the count would be
// telling them about the other recipients.
$downloads = $this->ownDownloads->forMany($fileRows, $client);
return Inertia::render("portal/themes/{$this->themeKey()}/my-files", [ return Inertia::render("portal/themes/{$this->themeKey()}/my-files", [
'folder' => $current === null ? null : ['id' => $current->id, 'name' => $current->name], 'folder' => $current === null ? null : ['id' => $current->id, 'name' => $current->name],
@@ -237,6 +261,14 @@ class MyFilesController extends Controller
'size' => $file->size, 'size' => $file->size,
'created_at' => $file->created_at?->toIso8601String(), 'created_at' => $file->created_at?->toIso8601String(),
'is_mine' => $file->uploaded_by === $client->id, 'is_mine' => $file->uploaded_by === $client->id,
// Decided per row by FilePolicy, exactly as the folder rows
// above are: a client's own uploads are theirs to manage
// and files shared with them are not, and both kinds sit in
// the same list. A theme reads these and never works them
// out from is_mine — holding the file is only half of it,
// the role's keys are the other half.
'can_update' => Gate::forUser($client)->allows('update', $file),
'can_delete' => Gate::forUser($client)->allows('delete', $file),
// Effective status (own flag or inherited from a public // Effective status (own flag or inherited from a public
// folder) — same "will visitors on the public site see // folder) — same "will visitors on the public site see
// this" badge as the staff library shows. // this" badge as the staff library shows.
@@ -247,6 +279,19 @@ class MyFilesController extends Controller
// counterpart they were not given is null, not hidden by // counterpart they were not given is null, not hidden by
// the theme. A theme must never filter this itself. // the theme. A theme must never filter this itself.
'version' => $versions[$file->id] ?? ['previous' => null, 'next' => null], 'version' => $versions[$file->id] ?? ['previous' => null, 'next' => null],
// The public URL for a file of their own, where one
// exists. Null on a file somebody shared with them, and
// null on their own file that has no link — a client has
// no way to mint one, so this is populated only where the
// installation did it for them. Never derived from
// is_mine: a theme renders what is here and nothing else.
'share_url' => $shareUrls[$file->id] ?? null,
// How often this went out and when it last did — the
// answer to "did it arrive?", which on a link-only
// account is the only evidence there is. Null on a file
// somebody shared with this client: not zero, which would
// be a claim about other people's activity, but nothing.
'downloads' => $downloads[$file->id] ?? null,
'categories' => $file->categories->map(fn (Category $category): array => [ 'categories' => $file->categories->map(fn (Category $category): array => [
'id' => $category->id, 'name' => $category->name, 'color' => $category->color, 'id' => $category->id, 'name' => $category->name, 'color' => $category->color,
])->values()->all(), ])->values()->all(),
@@ -306,6 +351,200 @@ class MyFilesController extends Controller
]); ]);
} }
/**
* The editor page for a file this client uploaded.
*
* One page for every theme, not one per theme — the same shape
* `upload()` uses, and for the same reason: this is a form, and a form
* rebuilt four times is four places for a field to go missing. The
* `theme` prop picks the shell (see portal/edit-file.tsx), which is the
* only part that differs.
*
* Every `can_*` prop below is the *same* question ApplyFileEdits will
* ask when the form posts. A control this page hides is not a control
* the server then trusts: hiding it is a courtesy so a client is not
* shown a switch that will silently do nothing, and the refusal is
* server-side either way.
*/
public function edit(Request $request, File $file): Response
{
$client = $request->user();
abort_unless($client !== null && $client->isClient(), 404);
Gate::authorize('update', $file);
$file->loadMissing('categories');
return Inertia::render('portal/edit-file', [
'theme' => $this->themeKey(),
'file' => [
'id' => $file->id,
'name' => $file->name,
'description' => $file->description,
'original_name' => $file->original_name,
'size' => $file->size,
'public' => $file->public,
'commentable' => $file->commentable,
// The stored instant as the calendar day this client's own
// zone shows — the value the form posts back untouched, and
// the one update() compares against to tell a real change
// from a date that merely came along with a rename.
'expires_at' => $this->expiry->asShown($file, $client),
'download_limit' => $file->download_limit,
'download_limit_scope' => ($file->download_limit_scope ?? DownloadLimitScope::Total)->value,
'folder_id' => $file->folder_id,
'categories' => $file->categories->pluck('id')->all(),
],
'can_delete' => Gate::forUser($client)->allows('delete', $file),
'can_publish' => $client->can('upload_public'),
'can_set_expiration' => $client->can('set_file_expiration_date'),
'can_set_categories' => $client->can('set_file_categories'),
'can_limit_downloads' => $client->can('limit_downloads'),
// Only while the installation asks per file; otherwise the
// setting decides and the switch would be a lie.
'can_set_commentable' => $this->commenting->scope() === CommentScope::SelectedFiles,
'categories' => Category::query()->orderBy('name')->get(['id', 'name', 'color'])
->map(fn (Category $category): array => [
'id' => $category->id, 'name' => $category->name, 'color' => $category->color,
])->all(),
// Somewhere this client could have uploaded it in the first
// place — the same rule update() enforces, so the picker cannot
// offer a destination the save would refuse.
'folders' => Folder::query()->visibleToClient($client)->orderBy('name')->get()
->filter(fn (Folder $folder): bool => Folder::uploadableBy($client, $folder))
->map(fn (Folder $folder): array => [
'id' => $folder->id,
'name' => $folder->name,
// A destination can publish the file without the public
// switch being touched: File::isEffectivelyPublic() is
// "my own flag OR my folder's", and a client holding
// upload_to_public_folders may move into a public
// folder without holding upload_public. That is the
// established meaning of the two keys, and it is what
// uploading there has always done — but in a picker of
// bare names it would be invisible, so the name carries
// the consequence with it.
'public' => $folder->isEffectivelyPublic(),
])
->values()->all(),
// Public files are reachable at the installation's one public
// slug; without it configured, publishing shows nowhere and the
// page says so rather than offering a switch that does nothing
// visible.
'public_listing_slug' => $this->settings->get(Setting::PublicListingSlug),
]);
}
/**
* Edit a file this client uploaded.
*
* The client portal's counterpart to the staff file editor, and
* deliberately a separate route rather than the staff one opened up:
* `files.*` renders assignments, share links, activity and download
* history, which are staff surfaces, and its folder guard asks
* StaffLibraryScope — which answers "allowed" for every client (see
* FilePolicy::update()).
*
* Who may edit at all is FilePolicy: the file must be this client's own
* upload and they must hold `edit_files`. Which *fields* they may
* write is ApplyFileEdits, the same decision the staff editor and the
* API get, so a client holding `set_file_categories` but not
* `upload_public` gets exactly what those keys say and nothing is
* decided twice.
*/
public function update(Request $request, File $file): RedirectResponse
{
$client = $request->user();
abort_unless($client !== null && $client->isClient(), 404);
Gate::authorize('update', $file);
$validated = $request->validate([
'name' => ['required', 'string', 'max:255'],
'description' => ['nullable', 'string', 'max:2000'],
'folder_id' => Rules::folderId(),
'public' => ['sometimes', 'boolean'],
'commentable' => ['sometimes', 'boolean'],
'categories' => ['array'],
'categories.*' => ['integer', 'exists:categories,id'],
'expires_at' => ['nullable', 'date'],
'download_limit' => ['nullable', 'integer', 'min:1'],
'download_limit_scope' => ['nullable', Rule::enum(DownloadLimitScope::class)],
]);
// No `slug`, on purpose, and its absence is what makes
// ApplyFileEdits derive one from the name. An installation-wide
// unique slug that a client picks is a name to squat and an
// existence oracle to probe against every file on the
// installation, for nothing a derived slug does not already give
// them.
$folderId = isset($validated['folder_id']) ? (int) $validated['folder_id'] : null;
// The client rule, not the staff one: somewhere they could have
// uploaded it in the first place. Same check the upload path makes,
// so moving a file cannot reach a folder that uploading it could
// not. Only when the folder actually changes, so re-saving a file
// that already sits somewhere unusual still works.
if ($folderId !== null && $folderId !== $file->folder_id) {
$folder = Folder::query()->visibleToClient($client)->find($folderId);
abort_unless($folder !== null && Folder::uploadableBy($client, $folder), 403);
}
$changes = [
'name' => $validated['name'],
'description' => $validated['description'] ?? null,
'folder_id' => $folderId,
'commentable' => $validated['commentable'] ?? $file->commentable,
'download_limit' => $validated['download_limit'] ?? null,
'download_limit_scope' => $validated['download_limit_scope'] ?? DownloadLimitScope::Total->value,
'public' => $validated['public'] ?? $file->public,
'categories' => $validated['categories'] ?? [],
];
// Only when the date actually moved — the form posts back what it
// was rendered with, and re-deriving it on every save would shift
// the expiry by a timezone difference each time somebody renamed
// the file. See FileExpiry.
$posted = $validated['expires_at'] ?? null;
if ($posted !== $this->expiry->asShown($file, $client)) {
$changes['expires_at'] = $this->expiry->instant($posted, $client);
}
$this->fileEdits->apply($client, $file, $changes);
return back()->with('success', __('File updated.'));
}
/**
* Delete a file this client uploaded.
*
* Their own upload and `delete_files`, both settled by
* FilePolicy::delete(). A file merely shared with them is not theirs to
* remove, and no permission changes that.
*
* The row is soft-deleted and the bytes are not: File::booted()'s
* `deleted` hook removes the upload and every cached rendition on
* commit, so the client's storage quota — which sums untrashed rows —
* frees up by exactly what the disk does.
*/
public function destroy(Request $request, File $file): RedirectResponse
{
$client = $request->user();
abort_unless($client !== null && $client->isClient(), 404);
Gate::authorize('delete', $file);
$name = $file->name;
$file->delete();
$this->activity->log(Action::FileDeleted, context: ['name' => $name]);
return redirect()->route('my-files.index')->with('success', __('File deleted.'));
}
/** /**
* Files this client may name as the previous version of what they are * Files this client may name as the previous version of what they are
* uploading — THEIR OWN UPLOADS ONLY. * uploading — THEIR OWN UPLOADS ONLY.
app/Modules/Files/Http/Controllers/PublicShareController.php
+1 -1
View File
@@ -13,9 +13,9 @@ use App\Modules\Files\Models\Category;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Files\Models\ShareLink; use App\Modules\Files\Models\ShareLink;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Response;
use Inertia\Inertia; use Inertia\Inertia;
use Inertia\Response as InertiaResponse; use Inertia\Response as InertiaResponse;
use Symfony\Component\HttpFoundation\Response;
/** /**
* The public, unauthenticated side of a share link: no Gate/policy is * The public, unauthenticated side of a share link: no Gate/policy is
app/Modules/Files/Http/Controllers/ShareLinksController.php
+12 -10
View File
@@ -9,6 +9,7 @@ use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Files\Models\ShareLink; use App\Modules\Files\Models\ShareLink;
use App\Modules\Files\Sharing\CreateShareLink;
use App\Modules\Platform\Localization\LocalDay; use App\Modules\Platform\Localization\LocalDay;
use App\Modules\Platform\Localization\TimezoneRegistry; use App\Modules\Platform\Localization\TimezoneRegistry;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
@@ -30,6 +31,7 @@ class ShareLinksController extends Controller
public function __construct( public function __construct(
private readonly ActivityLogger $activity, private readonly ActivityLogger $activity,
private readonly TimezoneRegistry $timezones, private readonly TimezoneRegistry $timezones,
private readonly CreateShareLink $links,
) {} ) {}
public function store(Request $request, File $file): RedirectResponse public function store(Request $request, File $file): RedirectResponse
@@ -80,16 +82,16 @@ class ShareLinksController extends Controller
]); ]);
} }
ShareLink::query()->create([ // The permission gates stay here, where the request is: whether
'shareable_type' => $file->getMorphClass(), // this person may set an expiry or a cap is a fact about them,
'shareable_id' => $file->id, // not about link creation, and the action has no viewer to ask.
'token' => $validated['token'] ?? Str::random(32), $this->links->for(
'created_by' => $user->id, file: $file,
'expires_at' => $user->can('set_file_expiration_date') ? $expiresAt : null, creator: $user,
'max_downloads' => $user->can('limit_downloads') ? $validated['max_downloads'] ?? null : null, expiresAt: $user->can('set_file_expiration_date') ? $expiresAt : null,
]); maxDownloads: $user->can('limit_downloads') ? $validated['max_downloads'] ?? null : null,
token: $validated['token'] ?? null,
$this->activity->log(Action::ShareLinkCreated, subject: $file); );
return back()->with('success', __('Public link created.')); return back()->with('success', __('Public link created.'));
} }
app/Modules/Files/Http/Controllers/ZipDownloadsController.php
+9 -7
View File
@@ -8,6 +8,7 @@ use App\Http\Controllers\Controller;
use App\Models\User; use App\Models\User;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Delivery\FileDelivery;
use App\Modules\Files\Access\DownloadAllowance; use App\Modules\Files\Access\DownloadAllowance;
use App\Modules\Files\Access\ViewableFileScope; use App\Modules\Files\Access\ViewableFileScope;
use App\Modules\Files\Jobs\BuildZipDownloadJob; use App\Modules\Files\Jobs\BuildZipDownloadJob;
@@ -21,10 +22,10 @@ use App\Support\ContentDisposition;
use Illuminate\Database\Eloquent\Collection; use Illuminate\Database\Eloquent\Collection;
use Illuminate\Http\JsonResponse; use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Http\Response;
use Illuminate\Support\Facades\Gate; use Illuminate\Support\Facades\Gate;
use Illuminate\Support\Facades\Storage; use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Number; use Illuminate\Support\Number;
use Symfony\Component\HttpFoundation\Response;
/** /**
* A folder's "Download as zip" button and the file listing's multi-select * A folder's "Download as zip" button and the file listing's multi-select
@@ -45,6 +46,7 @@ class ZipDownloadsController extends Controller
private readonly ViewableFileScope $viewable, private readonly ViewableFileScope $viewable,
private readonly DownloadAllowance $allowance, private readonly DownloadAllowance $allowance,
private readonly Settings $settings, private readonly Settings $settings,
private readonly FileDelivery $delivery,
) {} ) {}
public function store(Request $request): JsonResponse public function store(Request $request): JsonResponse
@@ -186,12 +188,12 @@ class ZipDownloadsController extends Controller
$size = Storage::disk('files')->size($path); $size = Storage::disk('files')->size($path);
return response('', 200, [ return $this->delivery->serve(
'X-Accel-Redirect' => '/protected-files/'.$path, $path,
'Content-Type' => 'application/zip', 'application/zip',
'Content-Disposition' => ContentDisposition::attachment($this->filenameFor($zipDownload)), ContentDisposition::attachment($this->filenameFor($zipDownload)),
'Content-Length' => (string) $size, $size,
]); );
} }
/** /**
app/Modules/Files/Http/Resources/Api/FileResource.php
+45 -6
View File
@@ -4,6 +4,7 @@ declare(strict_types=1);
namespace App\Modules\Files\Http\Resources\Api; namespace App\Modules\Files\Http\Resources\Api;
use App\Modules\Files\Access\ClientIdentityScope;
use App\Modules\Files\DownloadLimitScope; use App\Modules\Files\DownloadLimitScope;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Files\Models\FileAssignment; use App\Modules\Files\Models\FileAssignment;
@@ -26,6 +27,23 @@ use Illuminate\Http\Resources\Json\JsonResource;
* - `checksum` is included deliberately, since verifying an integration's * - `checksum` is included deliberately, since verifying an integration's
* own download is a real use case, and it reveals nothing about * own download is a real use case, and it reveals nothing about
* location. * location.
*
* Two fields are narrowed to the caller: the uploader and the assignment
* list both name clients, and a client-scoped account may hold a file whose
* uploader or co-recipients are clients off their own roster — the file is
* theirs to read, those names are not theirs to see. ClientIdentityScope is
* the rule; a name dropped here is dropped to null or out of the list, and
* an unscoped account is unaffected.
*
* That narrowing happens here rather than in the controllers, which is the opposite of how the version counterparts are
* handled a few files over — and deliberately so. Whether a counterpart may
* be named is a set-shaped question with a query to express it, so it is
* asked once in the caller's eager load. Whether a client may be named is a
* per-row check against the viewer's roster with no query to fold it into,
* and this resource is built at eight call sites across four controllers,
* two of them re-loading `assignments.assignable` after a write. Asking at
* the point of serialisation is the only version of this rule that cannot
* be forgotten by the ninth caller.
*/ */
class FileResource extends JsonResource class FileResource extends JsonResource
{ {
@@ -34,6 +52,15 @@ class FileResource extends JsonResource
*/ */
public function toArray(Request $request): array public function toArray(Request $request): array
{ {
$viewer = $request->user();
$identity = app(ClientIdentityScope::class);
// The morph class rather than ::class, matching ShareTargets: with
// a morph map registered the two disagree, and this line now
// decides which roster an entry is checked against, so getting it
// wrong would mean checking a group id against the client list.
$groupMorph = (new Group)->getMorphClass();
return [ return [
'id' => $this->id, 'id' => $this->id,
'name' => $this->name, 'name' => $this->name,
@@ -96,11 +123,16 @@ class FileResource extends JsonResource
]), ]),
// Name only. The uploader is a user record; their email address // Name only. The uploader is a user record; their email address
// is not part of what "this file exists" needs to say. // is not part of what "this file exists" needs to say. Null
'uploaded_by' => $this->whenLoaded('uploader', fn (): ?array => $this->uploader === null ? null : [ // when the uploader is a client the token's owner is not
'id' => $this->uploader->id, // scoped to; an unscoped account always gets the name.
'name' => $this->uploader->name, 'uploaded_by' => $this->whenLoaded(
]), 'uploader',
fn (): ?array => $identity->permits($viewer, $this->uploader) && $this->uploader !== null ? [
'id' => $this->uploader->id,
'name' => $this->uploader->name,
] : null,
),
'categories' => $this->whenLoaded('categories', fn (): array => $this->categories 'categories' => $this->whenLoaded('categories', fn (): array => $this->categories
->map(fn ($category): array => [ ->map(fn ($category): array => [
@@ -109,15 +141,22 @@ class FileResource extends JsonResource
]) ])
->all()), ->all()),
// Who the file is shared with, as far as this caller is
// concerned: a recipient the token's owner is not scoped to is
// left out rather than returned without a name.
'assignments' => $this->whenLoaded('assignments', fn (): array => $this->assignments 'assignments' => $this->whenLoaded('assignments', fn (): array => $this->assignments
->filter(fn (FileAssignment $assignment): bool => $assignment->assignable_type === $groupMorph
? $identity->permitsGroupId($viewer, (int) $assignment->assignable_id)
: $identity->permitsClientId($viewer, (int) $assignment->assignable_id))
->map(fn (FileAssignment $assignment): array => [ ->map(fn (FileAssignment $assignment): array => [
'type' => $assignment->assignable_type === Group::class ? 'group' : 'client', 'type' => $assignment->assignable_type === $groupMorph ? 'group' : 'client',
'id' => $assignment->assignable_id, 'id' => $assignment->assignable_id,
// getAttribute() rather than ->name: the relation is a // getAttribute() rather than ->name: the relation is a
// MorphTo over User|Group, so the property is only // MorphTo over User|Group, so the property is only
// knowable at runtime. Both targets carry a name. // knowable at runtime. Both targets carry a name.
'name' => $assignment->assignable?->getAttribute('name'), 'name' => $assignment->assignable?->getAttribute('name'),
]) ])
->values()
->all()), ->all()),
'links' => [ 'links' => [
app/Modules/Files/Jobs/BuildZipDownloadJob.php
+100 -17
View File
@@ -135,7 +135,14 @@ class BuildZipDownloadJob implements ShouldQueue
// count, is what lets the download action log exactly what it // count, is what lets the download action log exactly what it
// hands over instead of resolving the selection a second time // hands over instead of resolving the selection a second time
// against a scope that may have moved since. // against a scope that may have moved since.
$addedIds = []; //
// Keyed by id rather than appended to a list, because it is
// also what keeps a file out of the archive twice. The loose
// selection cannot repeat itself — one whereIn on the primary
// key — but a selected folder can hold a file that was also
// named loosely, and the cap is 10000 sources, so the check
// has to be a lookup rather than a scan.
$added = [];
foreach ((clone $visible)->whereIn('id', $zipDownload->file_ids)->get() as $file) { foreach ((clone $visible)->whereIn('id', $zipDownload->file_ids)->get() as $file) {
// Re-checked here for the same reason visibility is: the // Re-checked here for the same reason visibility is: the
@@ -150,11 +157,11 @@ class BuildZipDownloadJob implements ShouldQueue
$entryName = $this->dedupeName($usedNames, $this->entrySegment($file->original_name)); $entryName = $this->dedupeName($usedNames, $this->entrySegment($file->original_name));
$zip->addFile($this->localPathFor($file, $tempFiles), $entryName); $zip->addFile($this->localPathFor($file, $tempFiles), $entryName);
$totalSize += $file->size; $totalSize += $file->size;
$addedIds[] = $file->id; $added[$file->id] = true;
} }
foreach (Folder::query()->whereIn('id', $zipDownload->folder_ids)->get() as $folder) { foreach ($this->outermostFolders($zipDownload->folder_ids) as $folder) {
$totalSize += $this->addFolder($zip, $folder, $requester, $usedNames, $tempFiles, $visible, $skipped, $addedIds); $totalSize += $this->addFolder($zip, $folder, $requester, $usedNames, $tempFiles, $visible, $skipped, $added);
} }
// Re-checked here, not only in ZipDownloadsController: the // Re-checked here, not only in ZipDownloadsController: the
@@ -197,7 +204,7 @@ class BuildZipDownloadJob implements ShouldQueue
@unlink($tempFile); @unlink($tempFile);
} }
if ($written !== true || $addedIds === []) { if ($written !== true || $added === []) {
if ($written !== true) { if ($written !== true) {
// What the requester sees stays generic: a libzip // What the requester sees stays generic: a libzip
// string means nothing to them and can name a server // string means nothing to them and can name a server
@@ -229,8 +236,8 @@ class BuildZipDownloadJob implements ShouldQueue
'status' => ZipDownload::STATUS_READY, 'status' => ZipDownload::STATUS_READY,
'path' => $relativePath, 'path' => $relativePath,
'total_size' => $totalSize, 'total_size' => $totalSize,
'file_count' => count($addedIds), 'file_count' => count($added),
'contained_file_ids' => $addedIds, 'contained_file_ids' => array_keys($added),
'skipped_files' => $skipped === [] ? null : $skipped, 'skipped_files' => $skipped === [] ? null : $skipped,
]); ]);
} catch (Throwable $e) { } catch (Throwable $e) {
@@ -238,9 +245,21 @@ class BuildZipDownloadJob implements ShouldQueue
@unlink($tempFile); @unlink($tempFile);
} }
// Same division as the write failure above: the reason is the
// operator's, the sentence is the requester's. An exception
// message here has already named a disk in practice — "Disk
// [x] does not have a configured driver." — and can name a
// server path, and this column is shown to whoever asked for
// the archive, including clients.
Log::error('A zip download could not be built.', [
'zip_download_id' => $zipDownload->id,
'exception' => $e::class,
'reason' => $e->getMessage(),
]);
$zipDownload->update([ $zipDownload->update([
'status' => ZipDownload::STATUS_FAILED, 'status' => ZipDownload::STATUS_FAILED,
'error' => $e->getMessage(), 'error' => 'The zip archive could not be built.',
]); ]);
} }
} }
@@ -305,22 +324,51 @@ class BuildZipDownloadJob implements ShouldQueue
throw new \RuntimeException('Could not create a temp file for '.$file->original_name); throw new \RuntimeException('Could not create a temp file for '.$file->original_name);
} }
// Registered before anything else can fail. tempnam() has already
// created the file, and the caller's cleanup only knows the paths
// it was told about — so every throw between here and the end of
// the copy used to leave a zip-src- file behind for good.
$tempFiles[] = $tempPath;
$stream = Storage::disk($file->disk)->readStream($file->path); $stream = Storage::disk($file->disk)->readStream($file->path);
$out = fopen($tempPath, 'wb'); $out = fopen($tempPath, 'wb');
if ($stream === null || $out === false) { if ($stream === null || $out === false) {
if (is_resource($stream)) {
fclose($stream);
}
if ($out !== false) {
fclose($out);
}
throw new \RuntimeException('Could not read '.$file->original_name.' from its storage disk.'); throw new \RuntimeException('Could not read '.$file->original_name.' from its storage disk.');
} }
stream_copy_to_stream($stream, $out); try {
fclose($out); // A copy that stops early is a truncated member added to the
// archive as though it were the file: the build reports ready,
// and the recipient gets something that opens and is wrong.
// fclose is checked for the same reason it is in
// LocalPartStore: it flushes, so a volume that filled on the
// last buffer fails there rather than here.
$copied = stream_copy_to_stream($stream, $out);
$flushed = fclose($out);
$out = false;
if (is_resource($stream)) { if ($copied === false || ! $flushed) {
fclose($stream); throw new \RuntimeException('Could not copy '.$file->original_name.' from its storage disk.');
}
} finally {
if ($out !== false) {
fclose($out);
}
if (is_resource($stream)) {
fclose($stream);
}
} }
$tempFiles[] = $tempPath;
return $tempPath; return $tempPath;
} }
@@ -329,9 +377,9 @@ class BuildZipDownloadJob implements ShouldQueue
* @param array<int, string> $tempFiles * @param array<int, string> $tempFiles
* @param Builder<File> $visible every file the requester may read * @param Builder<File> $visible every file the requester may read
* @param list<array{id: int, name: string}> $skipped * @param list<array{id: int, name: string}> $skipped
* @param list<int> $addedIds every file really written into the archive * @param array<int, true> $added every file really written into the archive, keyed by id
*/ */
private function addFolder(ZipArchive $zip, Folder $folder, User $requester, array &$usedNames, array &$tempFiles, Builder $visible, array &$skipped, array &$addedIds): int private function addFolder(ZipArchive $zip, Folder $folder, User $requester, array &$usedNames, array &$tempFiles, Builder $visible, array &$skipped, array &$added): int
{ {
$allowance = app(DownloadAllowance::class); $allowance = app(DownloadAllowance::class);
@@ -342,6 +390,15 @@ class BuildZipDownloadJob implements ShouldQueue
$totalSize = 0; $totalSize = 0;
foreach ((clone $visible)->whereIn('folder_id', $subtreeIds)->get() as $file) { foreach ((clone $visible)->whereIn('folder_id', $subtreeIds)->get() as $file) {
// Already in the archive under another part of the selection —
// named loosely, or inside a folder selected before this one.
// Skipped rather than added again: a second entry is a second
// copy of the same bytes, and delivery charges one download
// however many copies went out.
if (isset($added[$file->id])) {
continue;
}
// Holding the folder does not entitle the requester to a file // Holding the folder does not entitle the requester to a file
// inside it whose own allowance is spent — same reason the // inside it whose own allowance is spent — same reason the
// per-file visibility filter is re-derived rather than // per-file visibility filter is re-derived rather than
@@ -357,12 +414,38 @@ class BuildZipDownloadJob implements ShouldQueue
$entryPath = $this->dedupeName($usedNames, $entryPath); $entryPath = $this->dedupeName($usedNames, $entryPath);
$zip->addFile($this->localPathFor($file, $tempFiles), $entryPath); $zip->addFile($this->localPathFor($file, $tempFiles), $entryPath);
$totalSize += $file->size; $totalSize += $file->size;
$addedIds[] = $file->id; $added[$file->id] = true;
} }
return $totalSize; return $totalSize;
} }
/**
* The selected folders with the redundant ones dropped: one that sits
* inside another selected folder is already covered by it.
*
* Zipping both would reach the same file twice, and which of the two
* paths the surviving entry ended up under would be decided by
* whatever order the database returned the rows in. Keeping the outer
* folder keeps the fuller path — Reports/Q1/report.pdf rather than
* Q1/report.pdf — and gives the same archive on every run.
*
* @param list<int> $folderIds
* @return Collection<int, Folder>
*/
private function outermostFolders(array $folderIds): Collection
{
/** @var Collection<int, Folder> $folders */
$folders = Folder::query()->whereIn('id', $folderIds)->orderBy('id')->get();
return $folders
->reject(fn (Folder $folder): bool => $folders->contains(
fn (Folder $other): bool => $other->id !== $folder->id
&& str_starts_with($folder->path, $other->subtreePathPrefix()),
))
->values();
}
/** /**
* @param Collection<int, Folder> $foldersById Every folder in the root's subtree, keyed by id. * @param Collection<int, Folder> $foldersById Every folder in the root's subtree, keyed by id.
*/ */
app/Modules/Files/Models/File.php
+20 -4
View File
@@ -110,8 +110,12 @@ class File extends Model
// an account's content — deletes many rows in one transaction, // an account's content — deletes many rows in one transaction,
// and anything that rolls it back afterwards puts every row // and anything that rolls it back afterwards puts every row
// back while the bytes are already gone: a loss nothing can // back while the bytes are already gone: a loss nothing can
// undo. Deferred, the worst case is bytes left on disk with no // undo. Deferred, the worst case is bytes left on disk with a
// row, which OrphanFileScanner already finds and reports. // row that is only trashed, and a scan will not offer those:
// OrphanFileScanner::knownPaths() counts a trashed row's path
// as claimed, on purpose, so nothing double-adopts a file still
// inside its erasure grace period. FileDiskCleanup's warning is
// therefore the only record that it happened.
// //
// Outside a transaction the callback runs immediately, so // Outside a transaction the callback runs immediately, so
// deleting one file is unchanged. Nested transactions only fire // deleting one file is unchanged. Nested transactions only fire
@@ -247,8 +251,20 @@ class File extends Model
/** /**
* A file's own expiration date — independent of any share link's. * A file's own expiration date — independent of any share link's.
* Null means never expires. Once past, the file is hidden from * Null means never expires. Once past, the file is hidden from
* clients and the public site (see scopeNotExpired) but staff keep * clients and the public site (see scopeNotExpired) and staff keep
* full access to view, download, and manage it. * full access to view, download, and manage it — with one boundary
* this used to leave out.
*
* A client-scoped staff member's library is their own uploads ∪ what
* each assigned client may see (StaffLibraryScope::buildFiles), and
* that second half is scopeVisibleToClient, which ends in
* notExpired(). So an expired file they held only through a client
* leaves their library too, while their own expired upload stays.
* That is deliberate: c8078f65 weighed widening it and left the
* boundary where it is, because scopeVisibleToClient is the single
* source of truth for client file access, and relabelled the
* expired-files widget instead. ExpiredFileStaffAccessTest pins both
* halves so the sentence above cannot drift from the code again.
*/ */
public function isExpired(): bool public function isExpired(): bool
{ {
app/Modules/Files/Models/Folder.php
+41 -7
View File
@@ -152,15 +152,26 @@ class Folder extends Model
} }
/** /**
* Whether $user may upload a new file directly into $folder (null = * Whether $user may put content into $folder (null = loose at the
* loose at the root, always allowed). * root, always allowed).
*
* **Read the name as "may place into", not "may upload into".** Every
* way a file arrives in a folder has to come through here, and the
* name cost us one advisory already: the publication rule below was
* written for GHSA-237r-jx85-j3hr and wired into the upload paths
* alone, because those are what the name suggested. Moving a file in,
* bulk-moving a selection in, reparenting one through the edit form,
* and dragging a whole folder into a public parent all put content
* somewhere too, and none of them asked (GHSA-rxf8-wh8v-jm9j). They
* ask now. Anything new that writes a `folder_id` or a `parent_id`
* belongs on this list.
* *
* Staff are held to the library boundary they are held to everywhere * Staff are held to the library boundary they are held to everywhere
* else: an unscoped staff member may use any folder, a client-scoped * else: an unscoped staff member may use any folder, a client-scoped
* one only the folders StaffLibraryScope already shows them. This is * one only the folders StaffLibraryScope already shows them. Callers
* the only place that decides it: every upload path — the web form, * that have already resolved the destination through
* the API and the chunked flow the browser actually posts to — comes * StaffLibraryScope::folders() have answered that half — the two are
* through here rather than checking folder_id for itself. * the same query — and call this for the publication half.
* *
* For a client this is unchanged, and is still the whole of the * For a client this is unchanged, and is still the whole of the
* check: they own the folder, or it is a public folder that opts into * check: they own the folder, or it is a public folder that opts into
@@ -174,7 +185,30 @@ class Folder extends Model
} }
if ($user->isStaff()) { if ($user->isStaff()) {
return app(StaffLibraryScope::class)->allowsFolder($user, $folder); if (! app(StaffLibraryScope::class)->allowsFolder($user, $folder)) {
return false;
}
// Being allowed to reach the folder is not the same as being
// allowed to publish, and putting a file in a public folder
// publishes it: isEffectivelyPublic() is "my own flag, or my
// folder's". So the destination reaches the property that
// `upload_public` guards, without ever touching the switch
// (GHSA-237r-jx85-j3hr).
//
// The keys already say this. The client branch below has always
// asked for `upload_to_public_folders` here, and
// MyFilesController's picker calls that the established meaning
// of the two — it was simply never asked on a staff role, which
// left that permission doing nothing at all for staff.
//
// Effectively public, not `public`: the flag is inherited down
// a subtree, so a private folder inside a public one publishes
// just the same and a check on the folder's own flag would walk
// straight past it.
return ! $folder->isEffectivelyPublic()
|| $user->can('upload_public')
|| $user->can('upload_to_public_folders');
} }
return $folder->isOwnedBy($user) return $folder->isOwnedBy($user)
app/Modules/Files/Preview/PreviewLog.php
+52
View File
@@ -0,0 +1,52 @@
<?php
declare(strict_types=1);
namespace App\Modules\Files\Preview;
use App\Models\User;
use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Models\File;
use Illuminate\Support\Facades\Cache;
/**
* One log row per viewer per file per five minutes, for both preview
* routes — FileThumbnailController::preview (signed in) and
* PublicGroupsController::preview (anonymous).
*
* Watching a video is a single deliberate act that the browser turns into
* dozens of Range requests, each arriving indistinguishable from someone
* clicking preview again. Cache::add is the whole mechanism: it writes
* only if the key is absent, so the first request through the window logs
* and the rest are silent, without a read-then-write race between two of
* them.
*
* Keyed by viewer, so one person's playback never suppresses another's
* view of the same file. An anonymous visitor has no account to key on,
* so the request IP stands in — the same substitute the API's rate
* limiter makes for an unauthenticated caller. It is a cache key with a
* five-minute life and never reaches the log, which keeps its own
* decision about recording an IP (see ActivityLogger::shouldRecordIp and
* Setting::DownloadIpLogging).
*
* Shared rather than restated, because the window is the rule: two copies
* of "five minutes" are two things to change and one to forget.
*/
class PreviewLog
{
private const WINDOW_MINUTES = 5;
public function __construct(
private readonly ActivityLogger $activity,
) {}
public function record(Action $action, File $file, ?User $viewer): void
{
$viewerKey = $viewer !== null ? (string) $viewer->id : 'ip:'.request()->ip();
if (Cache::add('file-preview-logged:'.$file->id.':'.$viewerKey, true, now()->addMinutes(self::WINDOW_MINUTES))) {
$this->activity->log($action, subject: $file);
}
}
}
app/Modules/Files/Sharing/ClientShareLinks.php
+78
View File
@@ -0,0 +1,78 @@
<?php
declare(strict_types=1);
namespace App\Modules\Files\Sharing;
use App\Models\User;
use App\Modules\Files\Models\File;
use App\Modules\Files\Models\ShareLink;
use Illuminate\Support\Collection;
/**
* The public URLs a client may be shown for their own files.
*
* A client's portal lists two kinds of file side by side: what they
* uploaded, and what somebody shared with them. Both can carry share
* links, and only one kind of link is theirs to see — a link a staff
* member minted for a file they were given is that staff member's
* decision about who may reach it, and handing the recipient the URL
* would turn "you may download this" into "you may pass this on to
* anyone".
*
* So the rule is narrow and stated once: **a link this client created, on
* a file this client uploaded.** Both halves, not either. Neither is
* redundant — a client-created link on a file they no longer own would
* outlive a reassignment, and a staff link on their own upload is still
* not theirs to hand out.
*
* Inactive links are left out rather than shown greyed: the only thing a
* client can do with this is copy it, and a URL that answers "this link
* has expired" is worse than no URL at all.
*
* Resolved for a whole page at a time. One query for the listing, not one
* per row.
*/
class ClientShareLinks
{
/**
* @param Collection<int, File> $files
* @return array<int, string> file id => URL, for the files that have one
*/
public function forMany(Collection $files, User $client): array
{
$own = $files
->filter(fn (File $file): bool => $file->uploaded_by === $client->id)
->pluck('id')
->map(fn ($id): int => (int) $id)
->all();
if ($own === []) {
return [];
}
$links = ShareLink::query()
->where('shareable_type', (new File)->getMorphClass())
->whereIn('shareable_id', $own)
->where('created_by', $client->id)
// Oldest first, so a file that somehow carries two is
// described by the one the client has already been given
// rather than by whichever the database returned today.
->orderBy('id')
->get();
$urls = [];
foreach ($links as $link) {
$fileId = (int) $link->shareable_id;
if (isset($urls[$fileId]) || ! $link->isActive()) {
continue;
}
$urls[$fileId] = route('share.show', $link->token);
}
return $urls;
}
}
app/Modules/Files/Sharing/CreateShareLink.php
+62
View File
@@ -0,0 +1,62 @@
<?php
declare(strict_types=1);
namespace App\Modules\Files\Sharing;
use App\Models\User;
use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Models\File;
use App\Modules\Files\Models\ShareLink;
use Carbon\CarbonInterface;
use Illuminate\Support\Str;
/**
* Minting a public link for a file, in one place.
*
* Extracted from ShareLinksController rather than invented: the
* controller is an HTTP handler behind `staff` middleware, and a link now
* needs creating from outside a request as well. Two copies of "make a
* token, write the row, log it" would drift, and the half most likely to
* drift is the token.
*
* **The token is the whole authorization.** There is nothing behind
* /s/{token} — no session, no second factor — so its only defence is
* being unguessable. Str::random(32) is about 190 bits, which is more
* than a UUID's 122; anything minted here gets that and never a chosen
* value. A caller that wants a chosen token is a person typing one into a
* form, and that path stays in the controller where its minimum length
* can be argued about in a validation rule.
*
* Expiry and download caps are the caller's to decide and are passed in
* already resolved, because "the end of the 12th" depends on whose zone
* you are in and this class has no viewer.
*/
class CreateShareLink
{
public function __construct(
private readonly ActivityLogger $activity,
) {}
public function for(
File $file,
User $creator,
?CarbonInterface $expiresAt = null,
?int $maxDownloads = null,
?string $token = null,
): ShareLink {
$link = ShareLink::query()->create([
'shareable_type' => $file->getMorphClass(),
'shareable_id' => $file->id,
'token' => $token ?? Str::random(32),
'created_by' => $creator->id,
'expires_at' => $expiresAt,
'max_downloads' => $maxDownloads,
]);
$this->activity->log(Action::ShareLinkCreated, subject: $file);
return $link;
}
}
app/Modules/Files/Thumbnails/Events/ResolvingImageRendering.php
+4 -3
View File
@@ -14,9 +14,10 @@ use App\Modules\Files\Thumbnails\ImageRendition;
* *
* A thumbnail never asks: it is a rendering by definition, nothing else * A thumbnail never asks: it is a rendering by definition, nothing else
* would fit in a listing row. A preview is the case with two valid * would fit in a listing row. A preview is the case with two valid
* answers. Serving the stored file is far cheaper — an X-Accel-Redirect * answers. Serving the stored file is far cheaper — handed to the web
* with no PHP in the path at all, or a redirect straight to external * server with no PHP in the path at all where that is possible, or a
* storage — and it is what this app has always done. Decoding and * redirect straight to external storage — and it is what this app has
* always done. Decoding and
* re-encoding a full-size photograph instead is only worth it when * re-encoding a full-size photograph instead is only worth it when
* something actually intends to change what the viewer sees. * something actually intends to change what the viewer sees.
* *
app/Modules/Files/Thumbnails/ThumbnailGenerator.php
+127 -1
View File
@@ -6,6 +6,8 @@ namespace App\Modules\Files\Thumbnails;
use App\Modules\Files\Thumbnails\Events\RenderingImage; use App\Modules\Files\Thumbnails\Events\RenderingImage;
use claviska\SimpleImage; use claviska\SimpleImage;
use Illuminate\Contracts\Cache\LockTimeoutException;
use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\Event; use Illuminate\Support\Facades\Event;
use RuntimeException; use RuntimeException;
@@ -102,12 +104,111 @@ class ThumbnailGenerator
}; };
} }
/**
* How long a render may hold the lock before another request is
* entitled to assume it died. Generous: a 40-megapixel decode is a
* second or two, and an external source is copied local first.
*/
private const LOCK_SECONDS = 120;
/**
* How long to wait for the request that got there first.
*
* Waiting costs an idle worker — about 35 MB. Rendering costs that
* plus four bytes per source pixel, up to 160 MB at the megapixel
* ceiling. Waiting is the cheap option by an order of magnitude,
* which is the whole reason this exists.
*
* Configurable because the right number depends on how long a decode
* takes here, and that is a property of the machine rather than of
* the application: a small VPS reading a large source off a slow disk
* wants longer than this, and nothing in the code can know that.
*/
private const DEFAULT_LOCK_WAIT_SECONDS = 15;
/**
* Render one image, once, however many requests ask at the same time.
*
* **Why the lock.** Renditions are generated on demand and cached by
* existence, and nothing between the callers stopped two requests
* rendering the same image at once. The atomic rename below settles
* which file survives — it never stopped both from decoding. So N
* concurrent requests for one cold rendition were N full-size decodes,
* each holding four bytes per source pixel.
*
* That is not an attack. A public listing emits a thumbnail URL per
* file, a browser opens six or more connections at once, and the first
* visit to a gallery of ordinary camera images is six simultaneous
* decodes on a container sized for one. It kills the container, and
* because a killed render writes nothing, the cache never warms: the
* page dies again on the next visit. `PublicGroupsController` reaches
* here with no account at all.
*
* **Why waiting rather than refusing.** The request that waits holds
* an idle worker. The request that renders holds a worker plus the
* whole source bitmap. Six waiters cost what one renderer costs, so
* blocking is the cheap answer even when it looks like the slow one.
*
* **Why the re-check after acquiring.** The winner has finished by the
* time a waiter gets in, so the file it was waiting for is already
* there. Re-reading is what turns a wait into a cache hit rather than
* a second render of the same image.
*/
public function generate( public function generate(
string $sourcePath, string $sourcePath,
string $destinationPath, string $destinationPath,
string $mimeType, string $mimeType,
ImageAudience $audience, ImageAudience $audience,
ImageRendition $rendition, ImageRendition $rendition,
): void {
// Keyed on the destination, which already encodes the file, the
// audience and the rendition — two requests collide here exactly
// when they would have written the same path.
$lock = Cache::lock('rendition:'.sha1($destinationPath), self::LOCK_SECONDS);
try {
$lock->block($this->lockWaitSeconds());
} catch (LockTimeoutException) {
// Deliberately not rendering anyway. Falling through on
// timeout would reinstate exactly the pile-on this exists to
// stop, at the moment the system is already struggling — one
// failed thumbnail is a better outcome than a container that
// dies and takes the warm cache with it.
throw new RuntimeException('Timed out waiting for another request to render this image.');
}
try {
// Somebody else rendered it while we waited. An empty file is
// not a rendition — same rule the callers apply, and the same
// reason: nothing invalidates one once it is cached.
if (is_file($destinationPath) && filesize($destinationPath) > 0) {
return;
}
$this->render($sourcePath, $destinationPath, $mimeType, $audience, $rendition);
} finally {
$lock->release();
}
}
/**
* Clamped to at least a second: a zero would make every concurrent
* request fail instead of waiting, which is the opposite of the point
* and exactly what a stray empty environment variable produces.
*/
private function lockWaitSeconds(): int
{
$configured = config('projectsend.rendition_lock_wait_seconds');
return max(1, is_numeric($configured) ? (int) $configured : self::DEFAULT_LOCK_WAIT_SECONDS);
}
private function render(
string $sourcePath,
string $destinationPath,
string $mimeType,
ImageAudience $audience,
ImageRendition $rendition,
): void { ): void {
$dimensions = @getimagesize($sourcePath); $dimensions = @getimagesize($sourcePath);
@@ -134,6 +235,31 @@ class ThumbnailGenerator
// listening the image is written exactly as produced above. // listening the image is written exactly as produced above.
Event::dispatch(new RenderingImage($image, $mimeType, $audience, $rendition)); Event::dispatch(new RenderingImage($image, $mimeType, $audience, $rendition));
$image->toFile($destinationPath, $mimeType); // Written beside the destination and renamed into place, so the
// cached path never exists half-finished. Both callers test only
// that the path exists and then serve whatever is there
// (FileThumbnailController::render, PublicGroupsController::
// thumbnail), and nothing ever invalidates a rendition —
// RenderedImageCache::flush() runs on an event no core code raises.
// A render that died partway would therefore be served as the
// rendition from then on.
//
// It also settles the race: two requests rendering the same file at
// once used to encode into one path together. rename() within a
// directory is atomic and replaces what is there, so now the loser
// leaves a complete rendition behind rather than a mixture of two.
$temporaryPath = $destinationPath.'.'.bin2hex(random_bytes(8)).'.partial';
try {
$image->toFile($temporaryPath, $mimeType);
if (! rename($temporaryPath, $destinationPath)) {
throw new RuntimeException('Could not move the rendered image into place.');
}
} finally {
if (is_file($temporaryPath)) {
@unlink($temporaryPath);
}
}
} }
} }
app/Modules/Files/Uploads/LocalPartStore.php
+158 -73
View File
@@ -27,6 +27,12 @@ use Throwable;
*/ */
class LocalPartStore class LocalPartStore
{ {
/**
* Said twice, because a full temp volume can announce itself in the
* middle of the copy or only when the last buffer is flushed.
*/
private const WRITE_FAILED = 'Could not assemble the upload: writing to the temporary directory failed.';
/** /**
* The route name is a parameter because the same flow is mounted twice: * The route name is a parameter because the same flow is mounted twice:
* once on the session-authenticated web routes for the browser, once on * once on the session-authenticated web routes for the browser, once on
@@ -112,6 +118,25 @@ class LocalPartStore
return md5_file($path) ?: ''; return md5_file($path) ?: '';
} }
/**
* What one part number currently weighs on disk, 0 if it has never
* arrived. Read before and after a part is received, so the session's
* reservation can be settled against what is really there rather than
* against what the request claimed it would send.
*/
public function partSize(UploadSession $session, int $partNumber): int
{
$path = $this->partPath($session, $partNumber);
if (! is_file($path)) {
return 0;
}
clearstatcache(true, $path);
return (int) (filesize($path) ?: 0);
}
/** /**
* @return list<array{PartNumber: int, Size: int, ETag: string}> * @return list<array{PartNumber: int, Size: int, ETag: string}>
*/ */
@@ -140,9 +165,21 @@ class LocalPartStore
} }
/** /**
* Stream-append parts in order onto the files disk, hashing as we * Stream-append parts in order onto the files disk, hashing as we go.
* go. Peak temp usage ≈ file size + one part (parts are unlinked *
* as they are consumed). * The parts stay on disk until the assembled bytes are safely on the
* target disk. ChunkedUploadsController's completion lock promises that
* "a later retry still works", and everything that can fail after the
* concatenation — reopening the copy, a disk refusing the write, the
* File row itself — happens while the client has nothing but this
* session to retry with. Unlinking each part as it was consumed left
* listParts() empty, so every later complete() answered "Upload is
* incomplete: missing parts" for good.
*
* The cost is temp space: peak usage is the whole file twice over
* (every part, plus the assembled copy) rather than the file plus one
* part. Both are freed by the abort() below the moment the write lands,
* and by the failure path the moment it does not.
* *
* @return array{path: string, disk: string, size: int, checksum: string} * @return array{path: string, disk: string, size: int, checksum: string}
*/ */
@@ -158,6 +195,93 @@ class LocalPartStore
} }
$assembledPath = $this->directory($session).'/assembled'; $assembledPath = $this->directory($session).'/assembled';
try {
[$size, $checksum] = $this->concatenate($session, $parts, $assembledPath);
$readStream = fopen($assembledPath, 'rb');
if ($readStream === false) {
throw new RuntimeException('Could not reopen assembled file.');
}
$diskEvent = new ResolvingUploadDisk($session->user);
Event::dispatch($diskEvent);
$disk = $diskEvent->disk;
$written = Storage::disk($disk)->writeStream($targetPath, $readStream);
if (is_resource($readStream)) {
fclose($readStream);
}
// The disks are configured with 'throw' => false, so a refused
// write is a `false` return rather than an exception — and the
// caller goes on to record a File row for bytes that were never
// stored. Losing an upload silently is worse than failing it, and
// this is the only place that can tell the difference: a real
// instance of it was a GCS bucket rejecting the adapter's ACL,
// which looked exactly like a successful upload.
if ($written === false) {
// The reason is lost by the time it gets here — 'throw' => false
// means Flysystem swallowed the exception rather than passing it
// on — so log what was attempted. Which bucket it was is the
// difference between reading this as "my credentials expired"
// and "I typed the wrong bucket name", and only the log can say
// it: the message below is shown to whoever was uploading, which
// includes clients, and a bucket name is not theirs to see.
Log::error('Upload could not be written to storage.', [
'disk' => $disk,
'bucket' => config('filesystems.disks.'.$disk.'.bucket'),
'driver' => config('filesystems.disks.'.$disk.'.driver'),
'path' => $targetPath,
]);
throw new RuntimeException(
'Could not write the assembled upload to the "'.$disk.'" disk. '
.'Check the storage backend is reachable and its credentials are still valid.'
);
}
} catch (Throwable $failure) {
// The half-written copy belongs to this attempt and the next one
// makes its own; the parts belong to the client, and they are
// what a retry needs. Deleting the copy here is also the only
// thing that removes it at all on this path — it used to sit in
// the session directory until the sweeper came round.
FileSystem::delete($assembledPath);
throw $failure;
}
$this->abort($session);
return [
'path' => $targetPath,
'disk' => $disk,
'size' => $size,
'checksum' => $checksum,
];
}
/**
* Concatenate the parts into $assembledPath, returning the byte count
* and the sha256 of what was written.
*
* Every read and every write is checked. They were not, and while a
* failing fwrite on a full volume is loud in practice — Laravel's
* error handler turns the warning into an ErrorException — loud there
* means a 500 carrying a PHP message, where the disk-refused-the-write
* case a few lines above becomes a sentence the person uploading can
* act on. A short write arriving without a warning would be worse
* still: $size and the hash describe the buffer that was read, so an
* unchecked one yields a truncated file with a checksum matching bytes
* that were never stored.
*
* @param list<array{PartNumber: int, Size: int, ETag: string}> $parts
* @return array{0: int, 1: string}
*/
private function concatenate(UploadSession $session, array $parts, string $assembledPath): array
{
$out = fopen($assembledPath, 'wb'); $out = fopen($assembledPath, 'wb');
if ($out === false) { if ($out === false) {
@@ -167,85 +291,46 @@ class LocalPartStore
$hash = hash_init('sha256'); $hash = hash_init('sha256');
$size = 0; $size = 0;
foreach ($parts as $part) { try {
$partPath = $this->partPath($session, $part['PartNumber']); foreach ($parts as $part) {
$in = fopen($partPath, 'rb'); $in = fopen($this->partPath($session, $part['PartNumber']), 'rb');
if ($in === false) { if ($in === false) {
fclose($out); throw new RuntimeException('Could not read part '.$part['PartNumber'].'.');
throw new RuntimeException('Could not read part '.$part['PartNumber'].'.');
}
while (! feof($in)) {
$buffer = fread($in, 1024 * 1024);
if ($buffer === false) {
break;
} }
fwrite($out, $buffer); try {
hash_update($hash, $buffer); while (! feof($in)) {
$size += strlen($buffer); $buffer = fread($in, 1024 * 1024);
if ($buffer === false) {
throw new RuntimeException('Could not read part '.$part['PartNumber'].'.');
}
if ($buffer !== '' && @fwrite($out, $buffer) !== strlen($buffer)) {
throw new RuntimeException(self::WRITE_FAILED);
}
hash_update($hash, $buffer);
$size += strlen($buffer);
}
} finally {
fclose($in);
}
} }
} catch (Throwable $failure) {
fclose($out);
fclose($in); throw $failure;
unlink($partPath);
} }
fclose($out); // fclose flushes, so a volume that filled up on the last buffer
// fails here rather than in the loop.
$readStream = fopen($assembledPath, 'rb'); if (! fclose($out)) {
throw new RuntimeException(self::WRITE_FAILED);
if ($readStream === false) {
throw new RuntimeException('Could not reopen assembled file.');
} }
$diskEvent = new ResolvingUploadDisk($session->user); return [$size, hash_final($hash)];
Event::dispatch($diskEvent);
$disk = $diskEvent->disk;
$written = Storage::disk($disk)->writeStream($targetPath, $readStream);
if (is_resource($readStream)) {
fclose($readStream);
}
// The disks are configured with 'throw' => false, so a refused
// write is a `false` return rather than an exception — and the
// caller goes on to record a File row for bytes that were never
// stored. Losing an upload silently is worse than failing it, and
// this is the only place that can tell the difference: a real
// instance of it was a GCS bucket rejecting the adapter's ACL,
// which looked exactly like a successful upload.
if ($written === false) {
// The reason is lost by the time it gets here — 'throw' => false
// means Flysystem swallowed the exception rather than passing it
// on — so log what was attempted. Which bucket it was is the
// difference between reading this as "my credentials expired"
// and "I typed the wrong bucket name", and only the log can say
// it: the message below is shown to whoever was uploading, which
// includes clients, and a bucket name is not theirs to see.
Log::error('Upload could not be written to storage.', [
'disk' => $disk,
'bucket' => config('filesystems.disks.'.$disk.'.bucket'),
'driver' => config('filesystems.disks.'.$disk.'.driver'),
'path' => $targetPath,
]);
throw new RuntimeException(
'Could not write the assembled upload to the "'.$disk.'" disk. '
.'Check the storage backend is reachable and its credentials are still valid.'
);
}
$this->abort($session);
return [
'path' => $targetPath,
'disk' => $disk,
'size' => $size,
'checksum' => hash_final($hash),
];
} }
public function abort(UploadSession $session): void public function abort(UploadSession $session): void
app/Modules/Files/Uploads/StoreUploadedFile.php
+9
View File
@@ -5,6 +5,8 @@ declare(strict_types=1);
namespace App\Modules\Files\Uploads; namespace App\Modules\Files\Uploads;
use App\Models\User; use App\Models\User;
use App\Modules\Files\Events\FileWasStored;
use Illuminate\Support\Facades\Event;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
@@ -52,6 +54,13 @@ class StoreUploadedFile
$this->activity->log($action, $uploader, $file); $this->activity->log($action, $uploader, $file);
// Every upload path converges here — the chunked flow staff and
// clients share, and the synchronous POST beside it — so a
// listener sees each upload once without knowing which route
// produced it. Dispatched after the row exists, so what it
// receives is a complete File.
Event::dispatch(new FileWasStored($file, $uploader));
return $file; return $file;
} }
app/Modules/Files/Uploads/UploadSession.php
+69
View File
@@ -9,6 +9,7 @@ use App\Modules\Files\Models\Folder;
use Illuminate\Database\Eloquent\Concerns\HasUuids; use Illuminate\Database\Eloquent\Concerns\HasUuids;
use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo; use Illuminate\Database\Eloquent\Relations\BelongsTo;
use Illuminate\Support\Facades\DB;
/** /**
* A resumable chunked upload in progress. Parts live on disk under the * A resumable chunked upload in progress. Parts live on disk under the
@@ -20,6 +21,7 @@ use Illuminate\Database\Eloquent\Relations\BelongsTo;
* @property int|null $previous_file_id * @property int|null $previous_file_id
* @property string $original_name * @property string $original_name
* @property int $size * @property int $size
* @property int $staged_bytes
* @property string|null $mime_type * @property string|null $mime_type
* @property string|null $description * @property string|null $description
* @property string $status * @property string $status
@@ -53,4 +55,71 @@ class UploadSession extends Model
{ {
return $this->user_id === $user->id; return $this->user_id === $user->id;
} }
/**
* Claim room on the temporary volume for a part that is about to
* arrive, returning false if the session has no room left.
*
* The claim is made before the bytes are read, and it is one
* statement, because neither weaker version holds. Checking the part
* directory and then writing leaves a gap that every other part
* currently in flight fits through — and the protocol sends parts in
* parallel, so the number of them is the caller's choice, not ours.
* Charging the real size afterwards is the same gap by another name.
*
* $replacing is what the part number already holds, since re-sending a
* part overwrites it rather than adding to it. That is an ordinary
* resume, not an attack.
*
* The ceiling is the size the session declared. A client cannot stage
* more than it said it was sending, which is the invariant the whole
* fix rests on: store() has already measured that declaration against
* the file-size limit and the storage quota, so bounding staged bytes
* by it puts temporary bytes under the same limits as stored ones.
*/
public function reserveStaged(int $bytes, int $replacing = 0): bool
{
$delta = $bytes - $replacing;
$query = static::query()->whereKey($this->getKey());
// Both bounds are rearranged so that the column is never part of a
// subtraction. `staged_bytes + :delta BETWEEN 0 AND size` reads
// naturally and is wrong: staged_bytes is BIGINT UNSIGNED, and on
// MySQL a negative delta makes that expression underflow and raise
// SQLSTATE 22003 — in the comparison, before any row is chosen, so
// the bound meant to prevent it is the thing that trips over it.
// SQLite has no unsigned integers, so the suite cannot see this at
// all; UploadSessionStagedBytesMysqlTest is what covers it.
if ($delta >= 0) {
if ($delta > $this->size) {
return false;
}
$query->where('staged_bytes', '<=', $this->size - $delta);
} else {
// Never give back more than is held.
$query->where('staged_bytes', '>=', -$delta);
}
return $query->update(['staged_bytes' => DB::raw(sprintf('staged_bytes + (%d)', $delta))]) === 1;
}
/**
* Replace a reservation with what the part actually weighs.
*
* Always called, whatever happened to the part: a body shorter than
* its Content-Length, a client that hung up mid-transfer, a part
* refused for being too long and deleted. Whatever is on disk now is
* the truth, and the difference goes back to the session — otherwise
* a client's own retries would slowly exhaust their room.
*/
public function settleStaged(int $reserved, int $actual): void
{
if ($reserved === $actual) {
return;
}
$this->reserveStaged($actual, $reserved);
}
} }
app/Modules/Files/Versions/FileVersions.php
+24 -4
View File
@@ -96,8 +96,9 @@ class FileVersions
DB::transaction(function () use ($file, $previous, $root, $actor): void { DB::transaction(function () use ($file, $previous, $root, $actor): void {
// Move, never drop: a revision holds no recipients of its // Move, never drop: a revision holds no recipients of its
// own, but the people who already had this file must not // own, but the people who already had this file must not
// lose it. Through FileSharing so each target still gets // lose it. Through FileSharing, so a target the root does
// its activity entry, notification and digest. // not hold yet still gets its activity entry, notification
// and digest — and only such a target, see below.
$this->moveAssignmentsToRoot($file, $root); $this->moveAssignmentsToRoot($file, $root);
$file->update([ $file->update([
@@ -544,8 +545,27 @@ class FileVersions
continue; continue;
} }
// firstOrCreate inside, so a target the root already has is a // A target the root already holds gains nothing here, so it
// no-op rather than a duplicate notification. // is skipped rather than handed to FileSharing::assign().
// That method's firstOrCreate makes the assignment row
// idempotent but not the three side effects under it, so such
// a target was told a file had been shared with it about a
// file it already had — on top of the file_new_version it
// gets from sharedAudience(), which is exactly the two
// notifications for one action link() resolves that audience
// early to avoid. copyAssignmentsFrom() below states the rule
// outright for its own case: nobody is gaining access, so the
// notification would be a lie.
$alreadyOnRoot = FileAssignment::query()
->where('file_id', $root->id)
->where('assignable_type', $target->getMorphClass())
->where('assignable_id', $target->getKey())
->exists();
if ($alreadyOnRoot) {
continue;
}
$this->sharing->assign($root, $target, $target->name); $this->sharing->assign($root, $target, $target->name);
} }
app/Modules/Groups/Http/Controllers/Api/GroupMembersController.php
+25 -2
View File
@@ -11,6 +11,7 @@ use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Groups\Http\Resources\Api\GroupResource; use App\Modules\Groups\Http\Resources\Api\GroupResource;
use App\Modules\Groups\Models\Group; use App\Modules\Groups\Models\Group;
use Illuminate\Database\Eloquent\Relations\BelongsToMany;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Validation\ValidationException; use Illuminate\Validation\ValidationException;
@@ -56,7 +57,7 @@ class GroupMembersController extends Controller
$this->activity->log(Action::GroupMemberAdded, subject: $group, context: ['member' => $client->name]); $this->activity->log(Action::GroupMemberAdded, subject: $group, context: ['member' => $client->name]);
return new GroupResource($group->loadCount('members')->load('members')); return $this->response($group, $actor);
} }
public function destroy(Request $request, Group $group, User $member): GroupResource public function destroy(Request $request, Group $group, User $member): GroupResource
@@ -72,6 +73,28 @@ class GroupMembersController extends Controller
$this->activity->log(Action::GroupMemberRemoved, subject: $group, context: ['member' => $member->name]); $this->activity->log(Action::GroupMemberRemoved, subject: $group, context: ['member' => $member->name]);
return new GroupResource($group->loadCount('members')->load('members')); return $this->response($group, $actor);
}
/**
* The group as this actor may see it.
*
* GroupResource carries a name and an email per member, and its own
* docblock puts the boundary here: "the controller loading this
* relation is where that narrowing is applied". Api\GroupsController
* ::show() applies it for the read of the same group; changing the
* membership is not a reason to be told more than reading it, so both
* halves narrow by the same query.
*
* The count is deliberately not narrowed. members_count is the size of
* the group, which is a fact about the group rather than about who is
* in it, and the web screen shows the same total.
*/
private function response(Group $group, User $actor): GroupResource
{
return new GroupResource($group->loadCount('members')->load([
'members' => fn (BelongsToMany $members) => $members
->whereIn('users.id', $this->scope->clients($actor)->select('id')),
]));
} }
} }
app/Modules/Groups/Http/Controllers/Api/GroupsController.php
+21 -3
View File
@@ -13,6 +13,7 @@ use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Groups\Models\Group; use App\Modules\Groups\Models\Group;
use App\Support\Rules; use App\Support\Rules;
use Illuminate\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Relations\BelongsToMany;
use Illuminate\Http\JsonResponse; use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Http\Resources\Json\AnonymousResourceCollection; use Illuminate\Http\Resources\Json\AnonymousResourceCollection;
@@ -40,7 +41,13 @@ class GroupsController extends Controller
'visibility' => ['nullable', Rule::in(['public', 'private'])], 'visibility' => ['nullable', Rule::in(['public', 'private'])],
]); ]);
$query = Group::query()->withCount('members'); $viewer = $request->user();
assert($viewer !== null);
// The API twin of the web listing's narrowing, and it has to be
// here rather than only there: the same disclosure through a token
// is the same disclosure (GHSA-r3hg-3fxw-rcmr).
$query = $this->scope->groups($viewer)->withCount('members');
if (($filters['search'] ?? null) !== null) { if (($filters['search'] ?? null) !== null) {
$search = $filters['search']; $search = $filters['search'];
@@ -56,9 +63,20 @@ class GroupsController extends Controller
return GroupResource::collection($this->polling->paginate($request, $query, 'groups')); return GroupResource::collection($this->polling->paginate($request, $query, 'groups'));
} }
public function show(Group $group): GroupResource public function show(Request $request, Group $group): GroupResource
{ {
return new GroupResource($group->loadCount('members')->load('members')); $viewer = $request->user();
assert($viewer !== null);
// The web edit screen's boundary, on its API twin: this is the read
// half of the group that update() and destroy() below already refuse
// to touch, and it hands back the membership with addresses.
abort_unless($this->scope->allowsGroupChange($viewer, $group), 404);
return new GroupResource($group->loadCount('members')->load([
'members' => fn (BelongsToMany $members) => $members
->whereIn('users.id', $this->scope->clients($viewer)->select('id')),
]));
} }
public function store(Request $request): JsonResponse public function store(Request $request): JsonResponse
app/Modules/Groups/Http/Controllers/GroupsController.php
+32 -6
View File
@@ -10,7 +10,6 @@ use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Access\StaffLibraryScope; use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Groups\Models\Group; use App\Modules\Groups\Models\Group;
use App\Modules\Identity\UserType;
use App\Support\Pagination; use App\Support\Pagination;
use App\Support\PublicUrl; use App\Support\PublicUrl;
use App\Support\Rules; use App\Support\Rules;
@@ -41,7 +40,14 @@ class GroupsController extends Controller
'visibility' => $validated['visibility'] ?? null, 'visibility' => $validated['visibility'] ?? null,
]; ];
$groups = Group::query() $viewer = $request->user();
assert($viewer !== null);
// Scoped, not Group::query(): a client-scoped staff member is told
// about a group because one of their clients is in it. Without
// this the listing showed every group on the installation, to a
// viewer who could reach nothing of theirs (GHSA-r3hg-3fxw-rcmr).
$groups = $this->scope->groups($viewer)
->withCount('members') ->withCount('members')
->when($filters['search'], fn (Builder $query, string $search) => $query->where(fn (Builder $q) => $q ->when($filters['search'], fn (Builder $query, string $search) => $query->where(fn (Builder $q) => $q
->where('name', 'like', "%{$search}%") ->where('name', 'like', "%{$search}%")
@@ -102,8 +108,18 @@ class GroupsController extends Controller
return $target->with('success', __('Group created.')); return $target->with('success', __('Group created.'));
} }
public function edit(Group $group): Response public function edit(Request $request, Group $group): Response
{ {
$viewer = $request->user();
assert($viewer !== null);
// The same reach question update() and destroy() ask, asked one
// step earlier. Without it this was the one group route holding no
// library boundary at all: a scoped staff member could open a group
// whose contents they cannot see, read its membership off the
// screen, and only be refused on save.
abort_unless($this->scope->allowsGroupChange($viewer, $group), 404);
return Inertia::render('groups/edit', [ return Inertia::render('groups/edit', [
'group' => [ 'group' => [
'id' => $group->id, 'id' => $group->id,
@@ -112,14 +128,24 @@ class GroupsController extends Controller
'description' => $group->description, 'description' => $group->description,
'public' => $group->public, 'public' => $group->public,
], ],
'members' => $group->members()->orderBy('name')->get() // Both lists narrow through StaffLibraryScope::clients(), which
// is the listing half of the rule this screen's buttons are
// already guarded with: a member outside the roster cannot be
// removed here (allowsGroupMembership refuses it), and a client
// outside it cannot be added. Naming them anyway, with their
// address, was the same mistake the client list made before
// that method existed. An unscoped viewer sees everything,
// unchanged.
'members' => $group->members()
->whereIn('users.id', $this->scope->clients($viewer)->select('id'))
->orderBy('name')
->get()
->map(fn (User $member): array => [ ->map(fn (User $member): array => [
'id' => $member->id, 'id' => $member->id,
'name' => $member->name, 'name' => $member->name,
'email' => $member->email, 'email' => $member->email,
])->all(), ])->all(),
'available_clients' => User::query() 'available_clients' => $this->scope->clients($viewer)
->where('type', UserType::Client)
->whereNotIn('id', $group->members()->pluck('users.id')) ->whereNotIn('id', $group->members()->pluck('users.id'))
->orderBy('name') ->orderBy('name')
->get() ->get()
app/Modules/Groups/Http/Controllers/PublicGroupsController.php
+22 -7
View File
@@ -9,11 +9,13 @@ use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Comments\CommentingRules; use App\Modules\Comments\CommentingRules;
use App\Modules\Files\Access\DownloadAllowance; use App\Modules\Files\Access\DownloadAllowance;
use App\Modules\Files\Delivery\FileDelivery;
use App\Modules\Files\Delivery\StoredFileResponse; use App\Modules\Files\Delivery\StoredFileResponse;
use App\Modules\Files\Models\Category; use App\Modules\Files\Models\Category;
use App\Modules\Files\Models\File; use App\Modules\Files\Models\File;
use App\Modules\Files\Models\Folder; use App\Modules\Files\Models\Folder;
use App\Modules\Files\Preview\PreviewKind; use App\Modules\Files\Preview\PreviewKind;
use App\Modules\Files\Preview\PreviewLog;
use App\Modules\Files\Thumbnails\ImageAudience; use App\Modules\Files\Thumbnails\ImageAudience;
use App\Modules\Files\Thumbnails\ImageRendition; use App\Modules\Files\Thumbnails\ImageRendition;
use App\Modules\Files\Thumbnails\LocalSourceFile; use App\Modules\Files\Thumbnails\LocalSourceFile;
@@ -32,12 +34,12 @@ use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Model;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Http\Response;
use Illuminate\Pagination\Paginator; use Illuminate\Pagination\Paginator;
use Illuminate\Support\Collection; use Illuminate\Support\Collection;
use Illuminate\Support\Facades\Storage; use Illuminate\Support\Facades\Storage;
use Inertia\Inertia; use Inertia\Inertia;
use Inertia\Response as InertiaResponse; use Inertia\Response as InertiaResponse;
use Symfony\Component\HttpFoundation\Response;
/** /**
* The guest-facing side of a public group: no Gate/policy involved (same * The guest-facing side of a public group: no Gate/policy involved (same
@@ -77,6 +79,7 @@ class PublicGroupsController extends Controller
public function __construct( public function __construct(
private readonly Settings $settings, private readonly Settings $settings,
private readonly ActivityLogger $activity, private readonly ActivityLogger $activity,
private readonly PreviewLog $previews,
private readonly DownloadAllowance $allowance, private readonly DownloadAllowance $allowance,
private readonly ThumbnailGenerator $thumbnails, private readonly ThumbnailGenerator $thumbnails,
private readonly PublicThemeRegistry $themes, private readonly PublicThemeRegistry $themes,
@@ -84,6 +87,7 @@ class PublicGroupsController extends Controller
private readonly CommentingRules $commenting, private readonly CommentingRules $commenting,
private readonly StoredFileResponse $bytes, private readonly StoredFileResponse $bytes,
private readonly LocalSourceFile $source, private readonly LocalSourceFile $source,
private readonly FileDelivery $delivery,
) {} ) {}
public function index(Request $request, string $publicSlug): InertiaResponse|RedirectResponse public function index(Request $request, string $publicSlug): InertiaResponse|RedirectResponse
@@ -251,6 +255,13 @@ class PublicGroupsController extends Controller
$disk = Storage::disk('files'); $disk = Storage::disk('files');
// An empty file is not a rendition — same rule as the signed-in
// twin in FileThumbnailController::render(), and the same reason:
// nothing invalidates one once it is cached.
if ($disk->exists($thumbnailPath) && $disk->size($thumbnailPath) === 0) {
$disk->delete($thumbnailPath);
}
if (! $disk->exists($thumbnailPath)) { if (! $disk->exists($thumbnailPath)) {
$disk->makeDirectory(dirname($thumbnailPath)); $disk->makeDirectory(dirname($thumbnailPath));
@@ -267,11 +278,11 @@ class PublicGroupsController extends Controller
)); ));
} }
return response('', 200, [ return $this->delivery->serve(
'X-Accel-Redirect' => '/protected-files/'.$thumbnailPath, $thumbnailPath,
'Content-Type' => $file->mime_type, $file->mime_type,
'Content-Disposition' => ContentDisposition::inline($file->original_name), ContentDisposition::inline($file->original_name),
]); );
} }
/** /**
@@ -298,7 +309,11 @@ class PublicGroupsController extends Controller
// nothing. // nothing.
abort_unless($this->allowance->allows($file, null), 403); abort_unless($this->allowance->allows($file, null), 403);
$this->activity->log(Action::PublicFilePreviewed, subject: $file); // Debounced exactly as the signed-in twin is, and for the same
// reason: a single visitor watching one video arrives here dozens
// of times. Without a viewer to key on, PreviewLog keys on the
// request IP.
$this->previews->record(Action::PublicFilePreviewed, $file, null);
return $this->bytes->inline($file); return $this->bytes->inline($file);
} }
app/Modules/Groups/Http/Resources/Api/GroupResource.php
+6 -3
View File
@@ -13,9 +13,12 @@ use Illuminate\Http\Resources\Json\JsonResource;
* @mixin Group * @mixin Group
* *
* Members carry a name and an email, which is what the group edit screen * Members carry a name and an email, which is what the group edit screen
* already shows to anyone holding `edit_groups`. They are attached only * shows the same viewer. That is a claim about the screen, so it holds
* when explicitly loaded, so a listing of groups does not become a bulk * only for as long as the screen does: both narrow the list to the
* export of every client's address. * clients the viewer may act on, and the controller loading this relation
* is where that narrowing is applied. They are attached only when
* explicitly loaded, so a listing of groups does not become a bulk export
* of every client's address.
*/ */
class GroupResource extends JsonResource class GroupResource extends JsonResource
{ {
app/Modules/Identity/AccountContentDeletion.php
+70 -8
View File
@@ -7,8 +7,10 @@ namespace App\Modules\Identity;
use App\Models\User; use App\Models\User;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Files\DeletedAccountContent; use App\Modules\Files\DeletedAccountContent;
use App\Modules\Identity\Models\Role; use App\Modules\Identity\Models\Role;
use Closure;
use Illuminate\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Builder;
use Illuminate\Http\Request; use Illuminate\Http\Request;
use Illuminate\Validation\Rule; use Illuminate\Validation\Rule;
@@ -32,21 +34,36 @@ class AccountContentDeletion
public function __construct( public function __construct(
private readonly DeletedAccountContent $content, private readonly DeletedAccountContent $content,
private readonly ActivityLogger $activity, private readonly ActivityLogger $activity,
private readonly StaffLibraryScope $scope,
) {} ) {}
/** /**
* Every other active account, for the reassignment-target picker. * Every other active account this viewer may be shown, for the
* $excludeId is omitted on index pages, where one candidate list is * reassignment-target picker. $excludeId is omitted on index pages,
* shared across every row and each row's own id is filtered out * where one candidate list is shared across every row and each row's
* client-side instead. * own id is filtered out client-side instead.
*
* The client half is narrowed by StaffLibraryScope, the same rule that
* narrows the list this picker sits next to: a client-scoped staff
* member is not shown the name of somebody they can reach nothing of,
* and a picker is no more a reason to hand one over than a listing is.
* Staff accounts are not narrowed anywhere in the application and are
* not narrowed here.
*
* An unscoped viewer's list is unchanged — StaffLibraryScope::clients()
* returns every client for them.
*
* $viewer is null only where the picker is about the installation
* rather than about a screen: the erasure default in privacy settings
* is stored once for everybody, behind edit_settings, so narrowing it
* by whoever happens to be editing would store the wrong answer.
* *
* @return array<int, array{id: int, name: string, role: string}> * @return array<int, array{id: int, name: string, role: string}>
*/ */
public function candidates(?int $excludeId = null): array public function candidates(?User $viewer, ?int $excludeId = null): array
{ {
return User::query() return $this->reachableTargets($viewer)
->when($excludeId, fn (Builder $query, int $id) => $query->whereKeyNot($id)) ->when($excludeId, fn (Builder $query, int $id) => $query->whereKeyNot($id))
->where('active', true)
->with('role') ->with('role')
->orderBy('name') ->orderBy('name')
->get() ->get()
@@ -79,17 +96,62 @@ class AccountContentDeletion
return []; return [];
} }
$viewer = $request->user();
return $request->validate([ return $request->validate([
'content_action' => ['required', Rule::in(['cascade_delete', 'reassign'])], 'content_action' => ['required', Rule::in(['cascade_delete', 'reassign'])],
'reassign_to_id' => [ 'reassign_to_id' => [
'required_if:content_action,reassign', 'required_if:content_action,reassign',
'integer', 'integer',
Rule::exists('users', 'id')->where('active', true),
Rule::notIn([$target->id]), Rule::notIn([$target->id]),
// The same question the picker asks, asked again of what
// came back from it. It used to be "exists, and is active",
// which is not the boundary the picker documents two
// methods up: a client-scoped staff member was shown their
// own roster and could name anybody, so deleting a roster
// client could hand that client's files and folders to a
// client on somebody else's roster — who then reads, edits
// and deletes them under the own-upload rules
// (GHSA-w29w-pj29-x7ww).
//
// One predicate for both, rather than a matching pair: a
// picker that promises a boundary the write does not keep
// is exactly what this was.
function (string $attribute, mixed $value, Closure $fail) use ($viewer): void {
if (! $this->reachableTargets($viewer)->whereKey($value)->exists()) {
// Deliberately the message an id that does not
// exist at all would get. "Not yours" and "not
// there" have to read the same, or refusing is how
// a scoped staff member enumerates the accounts
// outside their roster.
$fail('validation.exists')->translate();
}
},
], ],
]); ]);
} }
/**
* Every active account $viewer may hand content to: staff, who are
* narrowed nowhere in the application, plus the clients
* StaffLibraryScope shows them. An unscoped viewer gets everybody,
* because clients() returns everybody for them.
*
* $viewer is null only where the question is about the installation
* rather than about a screen — the erasure default in privacy
* settings, which is stored once for everybody.
*
* @return Builder<User>
*/
private function reachableTargets(?User $viewer): Builder
{
return User::query()
->when($viewer, fn (Builder $query, User $for) => $query->where(fn (Builder $reachable) => $reachable
->where('type', UserType::Staff)
->orWhereIn('id', $this->scope->clients($for)->select('users.id'))))
->where('active', true);
}
/** /**
* @param array{content_action?: string, reassign_to_id?: int} $validated * @param array{content_action?: string, reassign_to_id?: int} $validated
*/ */
app/Modules/Identity/AccountLookup.php
+81
View File
@@ -0,0 +1,81 @@
<?php
declare(strict_types=1);
namespace App\Modules\Identity;
use App\Models\User;
/**
* Finding the account that holds an address, exactly.
*
* `where('email', $address)` is not an exact match. It is whatever the
* database's collation says equality means, and the documented one here —
* `utf8mb4_unicode_ci`, in INSTALL.md and in config/database.php — folds
* accents:
*
* administrator@example.com = administrator@éxample.com -> 1
*
* Those are two different domains. `éxample.com` is `xn--xample-9ua.com`,
* a name somebody else can own and prove they own. So an attacker could
* register the second at an OIDC provider, verify it honestly, sign in,
* and be handed the first account — no password, no interaction from its
* owner, and an administrator session if that account was one
* (GHSA-wgxf-v8cr-37mj).
*
* ### Loose is right when refusing and wrong when selecting
*
* The same looseness protects elsewhere and is deliberately left alone.
* `AvailableEmailRule` and `ClientProvisioning::emailIsAvailable()` ask
* "is this address free?", and a collation that answers "no" to a
* near-miss refuses *more* registrations, which is the safe direction.
* This class is for the other question — "which account is this?" — where
* matching more than you meant hands somebody an account.
*
* ### Why the filtering is in PHP
*
* A `COLLATE utf8mb4_bin` in the query would work on MySQL and break
* everywhere else, and the test suite runs on SQLite, which is byte-exact
* and would never have shown the bug in the first place. Comparing here
* gives one answer on every driver, and it is the answer that does not
* depend on how somebody created their database.
*
* Case is still folded, because that is a real requirement rather than an
* accident: addresses are stored lowercased and a provider may send any
* case. `mb_strtolower` folds case without folding accents, which is
* exactly the line to draw.
*/
class AccountLookup
{
/**
* The account whose address is exactly this one, or null.
*
* @param bool $withTrashed include soft-deleted accounts — a
* deleted account still holds its address
* until erasure
*/
public function byEmail(string $email, bool $withTrashed = false): ?User
{
$query = $withTrashed ? User::withTrashed() : User::query();
// The database narrows, this decides. A collation that matches too
// much returns extra rows here and they are dropped; one that
// matches too little was never going to return the right row at
// all, which is a different bug and not one anybody has.
return $query->where('email', $email)->get()
->first(fn (User $user): bool => $this->isSameAddress($user->email, $email));
}
/**
* Whether two strings name the same mailbox: case-insensitively, and
* byte-exact about everything else.
*/
public function isSameAddress(?string $stored, ?string $given): bool
{
if ($stored === null || $given === null) {
return false;
}
return mb_strtolower(trim($stored), 'UTF-8') === mb_strtolower(trim($given), 'UTF-8');
}
}
app/Modules/Identity/Console/CreateAdminCommand.php
+47 -10
View File
@@ -8,6 +8,7 @@ use App\Models\User;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Identity\Erasure\AvailableEmailRule; use App\Modules\Identity\Erasure\AvailableEmailRule;
use App\Modules\Identity\FirstAdministrator;
use App\Modules\Identity\Models\Role; use App\Modules\Identity\Models\Role;
use App\Modules\Identity\Permissions\SystemRole; use App\Modules\Identity\Permissions\SystemRole;
use App\Modules\Identity\UserType; use App\Modules\Identity\UserType;
@@ -30,7 +31,14 @@ class CreateAdminCommand extends Command
public function handle(): int public function handle(): int
{ {
if ($this->option('if-none') && User::query()->where('type', UserType::Staff)->exists()) { $ifNone = (bool) $this->option('if-none');
// Asked early so an unattended boot does not prompt for a name and
// a password it is about to throw away. It is asked again below,
// under a lock, because this read on its own has the same hole the
// setup screen had: two containers coming up against one database
// both see no staff and both create an administrator.
if ($ifNone && $this->staffExists()) {
$this->info('A staff user already exists; nothing to do.'); $this->info('A staff user already exists; nothing to do.');
return self::SUCCESS; return self::SUCCESS;
@@ -57,15 +65,36 @@ class CreateAdminCommand extends Command
return self::FAILURE; return self::FAILURE;
} }
$user = User::create([ $create = function () use ($name, $email, $password): User {
'type' => UserType::Staff, $user = User::create([
'active' => true, 'type' => UserType::Staff,
'role_id' => Role::query()->where('name', SystemRole::SystemAdministrator->value)->value('id'), 'active' => true,
'name' => $name, 'role_id' => Role::query()->where('name', SystemRole::SystemAdministrator->value)->value('id'),
'email' => $email, 'name' => $name,
'password' => $password, 'email' => $email,
'email_verified_at' => now(), 'password' => $password,
]); ]);
// forceFill, for the reason SetupController gives beside it:
// email_verified_at is not in User::$fillable, so passing it
// into create() lost it without a word. Whoever provisioned
// this container supplied the address themselves.
$user->forceFill(['email_verified_at' => now()])->save();
return $user;
};
// Without --if-none an operator is asking for an administrator
// outright, whoever else exists, so there is nothing to claim.
$user = $ifNone
? FirstAdministrator::claim(fn (): bool => ! $this->staffExists(), $create)
: $create();
if ($user === null) {
$this->info('A staff user already exists; nothing to do.');
return self::SUCCESS;
}
app(ActivityLogger::class)->log(Action::UserCreated, null, $user); app(ActivityLogger::class)->log(Action::UserCreated, null, $user);
@@ -84,4 +113,12 @@ class CreateAdminCommand extends Command
return self::SUCCESS; return self::SUCCESS;
} }
/**
* @phpstan-impure another process can create one between two calls
*/
private function staffExists(): bool
{
return User::query()->where('type', UserType::Staff)->exists();
}
} }
app/Modules/Identity/Console/EraseAccountCommand.php
+5 -1
View File
@@ -5,6 +5,7 @@ declare(strict_types=1);
namespace App\Modules\Identity\Console; namespace App\Modules\Identity\Console;
use App\Models\User; use App\Models\User;
use App\Modules\Identity\AccountLookup;
use App\Modules\Identity\Erasure\AccountEraser; use App\Modules\Identity\Erasure\AccountEraser;
use Illuminate\Console\Command; use Illuminate\Console\Command;
@@ -25,7 +26,10 @@ class EraseAccountCommand extends Command
{ {
$email = (string) $this->argument('email'); $email = (string) $this->argument('email');
$user = User::withTrashed()->where('email', $email)->first(); // Exact: this deletes somebody permanently, and a collation that
// folds accents could hand it a different account than the one an
// operator typed. See AccountLookup.
$user = app(AccountLookup::class)->byEmail($email, withTrashed: true);
if ($user === null) { if ($user === null) {
$this->error("No account found for {$email}."); $this->error("No account found for {$email}.");
app/Modules/Identity/Erasure/AccountEraser.php
+20
View File
@@ -9,6 +9,7 @@ use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLog; use App\Modules\Audit\ActivityLog;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\DeletedAccountContent; use App\Modules\Files\DeletedAccountContent;
use App\Modules\Identity\UserType;
use App\Modules\Platform\Settings\Setting; use App\Modules\Platform\Settings\Setting;
use App\Modules\Platform\Settings\Settings; use App\Modules\Platform\Settings\Settings;
use Illuminate\Support\Facades\DB; use Illuminate\Support\Facades\DB;
@@ -102,6 +103,24 @@ class AccountEraser
$this->activity->logSystem(Action::AccountContentCascadeDeleted, ['name' => $user->name, ...$result]); $this->activity->logSystem(Action::AccountContentCascadeDeleted, ['name' => $user->name, ...$result]);
} }
/**
* The account configured to inherit erased content, or null when
* there is nobody valid to hand it to — in which case handleContent()
* cascades, because orphaning is never the answer.
*
* **A staff member's content may only go to staff.** The target is one
* installation-wide id used for every erasure, and the picker offers
* clients on purpose: erasing a client and handing their files to
* another client is what the setting is for. Applied to a *staff*
* account the same id means something else entirely — a staff library
* is usually the whole installation's, and a client named there would
* inherit all of it, in one unattended scheduled job.
*
* The check cannot live in the settings validation, which is where it
* would otherwise belong: that runs when the target is chosen, and
* whose account will be erased later is not knowable then. So it is
* asked here, where both halves are in hand.
*/
private function fallbackFor(User $user): ?User private function fallbackFor(User $user): ?User
{ {
$id = (int) $this->settings->get(Setting::AccountErasureReassignTo); $id = (int) $this->settings->get(Setting::AccountErasureReassignTo);
@@ -113,6 +132,7 @@ class AccountEraser
return User::query() return User::query()
->where('active', true) ->where('active', true)
->whereKeyNot($user->id) ->whereKeyNot($user->id)
->when($user->isStaff(), fn ($query) => $query->where('type', UserType::Staff))
->find($id); ->find($id);
} }
} }
app/Modules/Identity/FirstAdministrator.php
+65
View File
@@ -0,0 +1,65 @@
<?php
declare(strict_types=1);
namespace App\Modules\Identity;
use App\Models\User;
use App\Modules\Identity\Models\Role;
use App\Modules\Identity\Permissions\EnsureSystemRoles;
use App\Modules\Identity\Permissions\SystemRole;
use Illuminate\Support\Facades\DB;
/**
* Creating the very first administrator is a claim, not a check followed
* by an insert.
*
* "Has this installation been set up" is answered by asking whether any
* staff row exists, and an empty result has nothing in it to lock. So two
* unauthenticated setup requests arriving together both read "no staff",
* both spend a quarter of a second hashing a password, and both insert a
* System Administrator. The operator's own setup succeeds and looks
* entirely normal, which is the point: a stranger walks away with a
* second, permanent administrator account and nothing says so.
* (GHSA-w3w9-prpw-qx77, reported by @ry2811.)
*
* What gets locked is the System Administrator role row. It is the thing
* being claimed; it is written by the roles migration and rewritten on
* every boot, so unlike the staff rows it is always there to be locked.
* The second caller waits on it, and by the time it has the lock the
* first caller's user row is committed and visible — so its own re-check,
* asked inside the claim this time, sees an installation that is already
* set up and creates nothing.
*
* Locking the staff query itself would not do. There are no matching rows
* on a fresh install, and a lock over nothing serialises nothing.
*/
final class FirstAdministrator
{
/**
* Create the initial administrator, or nothing if somebody else got
* there first.
*
* @param callable(): bool $stillNeeded asked again with the claim held
* @param callable(): User $create runs only if it is still needed
* @return User|null null when the claim was lost
*/
public static function claim(callable $stillNeeded, callable $create): ?User
{
// The lock needs a row to bite on. This is idempotent and already
// runs on every boot; asking again costs one query on the one
// request in the life of an installation that comes through here,
// and means a database somehow missing its roles gets them back
// rather than quietly racing.
(new EnsureSystemRoles)->ensure();
return DB::transaction(function () use ($stillNeeded, $create): ?User {
Role::query()
->where('name', SystemRole::SystemAdministrator->value)
->lockForUpdate()
->value('id');
return $stillNeeded() ? $create() : null;
});
}
}
app/Modules/Identity/Http/Controllers/AccountConversionController.php
+20 -6
View File
@@ -7,6 +7,7 @@ namespace App\Modules\Identity\Http\Controllers;
use App\Http\Controllers\Controller; use App\Http\Controllers\Controller;
use App\Models\User; use App\Models\User;
use App\Modules\Api\Auth\ApiTokens; use App\Modules\Api\Auth\ApiTokens;
use App\Modules\Files\Access\StaffLibraryScope;
use App\Modules\Files\DeletedAccountContent; use App\Modules\Files\DeletedAccountContent;
use App\Modules\Identity\AccountConversion; use App\Modules\Identity\AccountConversion;
use App\Modules\Identity\Models\Role; use App\Modules\Identity\Models\Role;
@@ -26,10 +27,12 @@ use Inertia\Response;
/** /**
* Moving an account between staff and clients. * Moving an account between staff and clients.
* *
* Community edition only, by the same route group as every other * Both editions since 2.2.0, by the same route group as every other
* staff-account screen — managed installations create staff accounts * staff-account screen: whoever may create a staff account may promote
* outside the application, so a converter there would be a second, * one, and a managed installation limits that by seats rather than by
* unmanaged way to create one. * closing the screen — AccountConversion asks SeatAllowance on both
* directions, because a promotion spends a staff seat and a demotion
* spends a client one.
* *
* The rules live in AccountConversion, which calls StaffAccounts for the * The rules live in AccountConversion, which calls StaffAccounts for the
* authority questions. This controller is the request shape and the * authority questions. This controller is the request shape and the
@@ -44,6 +47,7 @@ class AccountConversionController extends Controller
private readonly StaffAccounts $accounts, private readonly StaffAccounts $accounts,
private readonly DeletedAccountContent $accountContent, private readonly DeletedAccountContent $accountContent,
private readonly ApiTokens $apiTokens, private readonly ApiTokens $apiTokens,
private readonly StaffLibraryScope $library,
) {} ) {}
public function index(Request $request): Response public function index(Request $request): Response
@@ -57,8 +61,18 @@ class AccountConversionController extends Controller
$search = $validated['search'] ?? null; $search = $validated['search'] ?? null;
$actor = $this->actor($request); $actor = $this->actor($request);
$accounts = User::query() // Narrowed for the direction that lists clients, by the same rule
->where('type', $direction === 'to_client' ? UserType::Staff : UserType::Client) // store() refuses one with: AccountConversion::guardToStaff() aborts
// 404 unless StaffLibraryScope::canAssignClient() allows the target,
// and clients() is that same method's listing half. Without this a
// client-scoped staff member was refused the promotion and then
// shown the person's name and address in the list it was refused
// from. Staff are not narrowed: whoever may demote a staff member
// may see the staff roster, which is what assignableRoles() and
// guardTarget() already decide on the write side.
$accounts = ($direction === 'to_client'
? User::query()->where('type', UserType::Staff)
: $this->library->clients($actor))
->with('role') ->with('role')
->when($search, fn (Builder $query, string $term) => $query->where(fn (Builder $inner) => $inner ->when($search, fn (Builder $query, string $term) => $query->where(fn (Builder $inner) => $inner
->where('name', 'like', "%{$term}%") ->where('name', 'like', "%{$term}%")
app/Modules/Identity/Http/Controllers/Api/UsersController.php
+26 -8
View File
@@ -26,12 +26,18 @@ use Illuminate\Validation\ValidationException;
/** /**
* Staff accounts over the API — the API twin of the /users screens. * Staff accounts over the API — the API twin of the /users screens.
* *
* **Community only.** Every route is behind `capability:users.manage`, so * Both editions since 2.2.0. Every route is behind
* a cloud install answers 403 `capability_unavailable`: managed * `capability:users.manage`, which cloud installations now hold as well:
* installations create staff accounts outside the application, and an API * a platform sells staff seats and the tenant fills them, so an API that
* that could mint them there would be a second, unmanaged door into the * creates one is the same door the screen is, not a second unmanaged one
* same thing. * (see Capability::UsersManage). How many it may create is
* The routes are still registered in every edition so the committed * SeatAllowance's question, asked here through StaffAccounts, and an
* installation at its limit answers 422 rather than 403.
*
* The capability stays in front of the routes rather than being dropped:
* it is the seam an edition difference would have to travel through, and
* an installation without it answers 403 `capability_unavailable`. The
* routes are registered in every edition either way, so the committed
* OpenAPI document is identical everywhere — the middleware refuses, the * OpenAPI document is identical everywhere — the middleware refuses, the
* route table does not lie. * route table does not lie.
* *
@@ -176,15 +182,27 @@ class UsersController extends Controller
'assigned_clients.*' => ['integer', Rule::in($this->accounts->assignableClientIds($actor))], 'assigned_clients.*' => ['integer', Rule::in($this->accounts->assignableClientIds($actor))],
]); ]);
// Read through Request::boolean() rather than off the validated
// array, for the reason RolesController::guardScopeRemoval spells
// out: the `boolean` rule accepts 0 and "0" as well as false but
// does not cast, so a strict comparison lets through a value the
// model's own `boolean` cast then stores as false anyway. The same
// value goes to the guard and to the write.
$deactivating = array_key_exists('active', $validated) && ! $request->boolean('active');
// The same refusal the web screen makes, and for the same reason: // The same refusal the web screen makes, and for the same reason:
// locking yourself out is never what was meant. // locking yourself out is never what was meant.
if ($user->is($actor) && ($validated['active'] ?? true) === false) { if ($user->is($actor) && $deactivating) {
throw ValidationException::withMessages([ throw ValidationException::withMessages([
'active' => __('You cannot deactivate your own account.'), 'active' => __('You cannot deactivate your own account.'),
]); ]);
} }
$attributes = array_intersect_key($validated, array_flip(['name', 'email', 'active', 'password'])); $attributes = array_intersect_key($validated, array_flip(['name', 'email', 'password']));
if (array_key_exists('active', $validated)) {
$attributes['active'] = $request->boolean('active');
}
if (array_key_exists('role_id', $validated)) { if (array_key_exists('role_id', $validated)) {
$attributes['role_id'] = (int) $validated['role_id']; $attributes['role_id'] = (int) $validated['role_id'];
app/Modules/Identity/Http/Controllers/SetupController.php
+52 -11
View File
@@ -8,6 +8,7 @@ use App\Http\Controllers\Controller;
use App\Models\User; use App\Models\User;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger; use App\Modules\Audit\ActivityLogger;
use App\Modules\Identity\FirstAdministrator;
use App\Modules\Identity\Models\Role; use App\Modules\Identity\Models\Role;
use App\Modules\Identity\Permissions\SystemRole; use App\Modules\Identity\Permissions\SystemRole;
use App\Modules\Identity\UserType; use App\Modules\Identity\UserType;
@@ -54,17 +55,46 @@ class SetupController extends Controller
'password' => ['required', 'confirmed', Password::defaults()], 'password' => ['required', 'confirmed', Password::defaults()],
]); ]);
$this->settings->set(Setting::SiteName, $validated['site_name']); // The check above is not enough on its own: it is a plain read, and
// between it and the insert a second setup request can do the same
// read and insert an administrator of its own. Everything this
// request writes therefore happens inside the claim, so a request
// that loses the race writes nothing at all — not the site name
// either. See FirstAdministrator.
$admin = FirstAdministrator::claim(
fn (): bool => ! $this->setupIsComplete(),
function () use ($validated): User {
$this->settings->set(Setting::SiteName, $validated['site_name']);
$admin = User::create([ $admin = User::create([
'type' => UserType::Staff, 'type' => UserType::Staff,
'active' => true, 'active' => true,
'role_id' => Role::query()->where('name', SystemRole::SystemAdministrator->value)->value('id'), 'role_id' => Role::query()->where('name', SystemRole::SystemAdministrator->value)->value('id'),
'name' => $validated['name'], 'name' => $validated['name'],
'email' => $validated['email'], 'email' => $validated['email'],
'password' => $validated['password'], 'password' => $validated['password'],
'email_verified_at' => now(), ]);
]);
// forceFill, not part of the create() array:
// email_verified_at is deliberately absent from
// User::$fillable, so mass assignment dropped it in silence
// and this account was never marked verified. The first
// administrator typed their own address into the form in
// front of them; there is nobody to confirm it to. (Inert
// today, since MustVerifyEmail is not enabled on the model,
// but the column is what a later switch would read.)
$admin->forceFill(['email_verified_at' => now()])->save();
return $admin;
},
);
// Somebody else finished setup while this request was in flight.
// Theirs is the administrator that exists; this one is sent to the
// login screen like any other visitor to an installed site.
if ($admin === null) {
return redirect()->route('home');
}
// v1 logged installation as action 0; setup is a recorded action. // v1 logged installation as action 0; setup is a recorded action.
$this->activity->log(Action::SetupCompleted, $admin); $this->activity->log(Action::SetupCompleted, $admin);
@@ -97,8 +127,19 @@ class SetupController extends Controller
return Inertia::render('setup-success'); return Inertia::render('setup-success');
} }
/**
* Trashed staff count, for the reason EnsureSetupIsComplete gives:
* this asks whether the installation was ever set up, and store()
* below is the door a stranger walks through if the answer is wrong.
* The middleware and this must agree — one of them saying "not set
* up" while the other says "set up" is either a redirect loop or an
* open form.
*
* @phpstan-impure asking twice can honestly give two answers, which is
* the entire reason store() asks a second time under a lock
*/
private function setupIsComplete(): bool private function setupIsComplete(): bool
{ {
return User::query()->where('type', UserType::Staff)->exists(); return User::query()->withTrashed()->where('type', UserType::Staff)->exists();
} }
} }
app/Modules/Identity/Http/Controllers/UsersController.php
+35 -6
View File
@@ -14,6 +14,7 @@ use App\Modules\Identity\Models\Role;
use App\Modules\Identity\StaffAccounts; use App\Modules\Identity\StaffAccounts;
use App\Modules\Identity\TwoFactor\TwoFactorAdministration; use App\Modules\Identity\TwoFactor\TwoFactorAdministration;
use App\Modules\Identity\UserType; use App\Modules\Identity\UserType;
use App\Modules\Platform\Seats\SeatAllowance;
use App\Support\Pagination; use App\Support\Pagination;
use Illuminate\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Builder;
use Illuminate\Http\RedirectResponse; use Illuminate\Http\RedirectResponse;
@@ -26,9 +27,17 @@ use Inertia\Inertia;
use Inertia\Response; use Inertia\Response;
/** /**
* Staff ("system users") management — community edition only; managed * Staff ("system users") management. Clients are a different population
* installations create them outside the application. Clients are a different * managed by the Clients module: they never appear here.
* population managed by the Clients module: they never appear here. *
* Available on both editions since 2.2.0. A managed installation is sold a
* number of seats and fills them itself — see Capability::UsersManage for
* why capacity is the platform's and who fills it is the tenant's.
*
* That makes a full installation an ordinary state rather than an error,
* so `index()` reports the seat position and `create()` refuses to open a
* form nothing can be submitted through. SeatAllowance::guardStaff() still
* runs in `store()`: this is the courtesy, that is the rule.
*/ */
class UsersController extends Controller class UsersController extends Controller
{ {
@@ -37,6 +46,7 @@ class UsersController extends Controller
private readonly AccountContentDeletion $accountDeletion, private readonly AccountContentDeletion $accountDeletion,
private readonly ApiTokens $apiTokens, private readonly ApiTokens $apiTokens,
private readonly StaffAccounts $accounts, private readonly StaffAccounts $accounts,
private readonly SeatAllowance $seats,
) {} ) {}
public function index(Request $request): Response public function index(Request $request): Response
@@ -98,12 +108,29 @@ class UsersController extends Controller
'filters' => $filters, 'filters' => $filters,
'roles' => Role::query()->orderBy('name')->get(['id', 'name']) 'roles' => Role::query()->orderBy('name')->get(['id', 'name'])
->map(fn (Role $role): array => ['id' => $role->id, 'name' => $role->name])->all(), ->map(fn (Role $role): array => ['id' => $role->id, 'name' => $role->name])->all(),
'reassign_candidates' => $this->accountDeletion->candidates(), // Same rule as the clients list: the picker belongs to the
// delete dialog, so it is sent to whoever may open one.
'reassign_candidates' => $this->actor()->can('delete_users')
? $this->accountDeletion->candidates($this->actor())
: [],
// Null on a self-hosted install: no limit, nothing to say.
'seats' => $this->seats->staffState(),
]); ]);
} }
public function create(): Response public function create(): RedirectResponse|Response
{ {
// Turned away here rather than on submit. Somebody reaching this
// by link or bookmark used to fill in a name, an email and a
// password they had to invent, and learn the installation was full
// from a validation error under the email field — which reads as a
// fault with the address rather than a fact about the plan.
$seats = $this->seats->staffState();
if ($seats !== null && $seats['full']) {
return redirect()->route('users.index')->with('error', $seats['message']);
}
return Inertia::render('users/create', [ return Inertia::render('users/create', [
'roles' => $this->roleOptions(), 'roles' => $this->roleOptions(),
'clients' => $this->clientOptions(), 'clients' => $this->clientOptions(),
@@ -161,7 +188,9 @@ class UsersController extends Controller
&& $this->accounts->isAdministratorRole($user->role_id) && $this->accounts->isAdministratorRole($user->role_id)
&& $this->accounts->activeAdministratorCount() === 1, && $this->accounts->activeAdministratorCount() === 1,
'content' => $this->accountContent->summarize($user), 'content' => $this->accountContent->summarize($user),
'reassign_candidates' => $this->accountDeletion->candidates($user->id), 'reassign_candidates' => $this->actor()->can('delete_users')
? $this->accountDeletion->candidates($this->actor(), $user->id)
: [],
// Read-only, deliberately: an administrator may see that an // Read-only, deliberately: an administrator may see that an
// integration exists and what it is allowed to do, but only // integration exists and what it is allowed to do, but only
// the owner can rename, re-scope or revoke it. See ApiTokens. // the owner can rename, re-scope or revoke it. See ApiTokens.
app/Modules/Identity/Http/Middleware/EnforceTwoFactor.php
+7 -2
View File
@@ -40,12 +40,17 @@ class EnforceTwoFactor
return $next($request); return $next($request);
} }
// password.confirm is on this list because the two-factor mutation // password.confirm* is on this list because the two-factor mutation
// routes now require it: without the exemption, enrolling would // routes now require it: without the exemption, enrolling would
// redirect to the confirm-password screen, which this middleware // redirect to the confirm-password screen, which this middleware
// would redirect straight back to two-factor.show — a loop that // would redirect straight back to two-factor.show — a loop that
// locks the user out of the only exit. // locks the user out of the only exit.
if ($request->routeIs('two-factor.*', 'password.confirm', 'logout', 'locale.update')) { //
// The pattern covers both halves of that screen. Naming only the
// GET left the form rendering and its submission redirected away,
// so the password was never confirmed and the loop stayed shut
// one step further along than before.
if ($request->routeIs('two-factor.*', 'password.confirm*', 'logout', 'locale.update')) {
return $next($request); return $next($request);
} }
app/Modules/Identity/Http/Middleware/EnsureSetupIsComplete.php
+11 -1
View File
@@ -16,6 +16,16 @@ use Symfony\Component\HttpFoundation\Response;
* sent to the first-run setup screen. The database is the only source of * sent to the first-run setup screen. The database is the only source of
* truth — no install flags. Client accounts do not count: setup is about * truth — no install flags. Client accounts do not count: setup is about
* having an administrator. * having an administrator.
*
* Trashed staff count. "Has this installation been set up" is not the
* same question as "does it have a working administrator right now", and
* only the first one belongs here: a soft-deleted staff row is still
* evidence that setup happened, and an installation that has lost its
* last administrator needs a recovery path, not a stranger filling in
* the first-run form. Deleting a staff account is guarded against
* reaching zero (StaffAccounts::guardLastAdministrator), so this is the
* second lock rather than the first — but the first one is asked at five
* separate doors, and this one is asked once.
*/ */
class EnsureSetupIsComplete class EnsureSetupIsComplete
{ {
@@ -25,7 +35,7 @@ class EnsureSetupIsComplete
return $next($request); return $next($request);
} }
if (User::query()->where('type', UserType::Staff)->exists()) { if (User::query()->withTrashed()->where('type', UserType::Staff)->exists()) {
return $next($request); return $next($request);
} }
app/Modules/Identity/Ldap/LdapProvisioner.php
+14
View File
@@ -8,6 +8,7 @@ use App\Models\User;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Clients\ClientProvisioning; use App\Modules\Clients\ClientProvisioning;
use App\Modules\Identity\AuthSource; use App\Modules\Identity\AuthSource;
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Str; use Illuminate\Support\Str;
/** /**
@@ -55,6 +56,19 @@ class LdapProvisioner
return null; return null;
} }
// Same reason as SocialProvisioner: a deleted account keeps its
// address until erasure removes the row, so provisioning over one
// raises a QueryException at the moment of login. Refused here, the
// sign-in fails the ordinary way instead, and a directory identity
// does not silently reclaim an account somebody deleted.
if (! $this->clients->addressIsFree($identity->email)) {
Log::warning('A directory identity was not provisioned: the address belongs to a deleted account.', [
'email' => $identity->email,
]);
return null;
}
return $this->clients->provision( return $this->clients->provision(
name: $identity->name, name: $identity->name,
email: $identity->email, email: $identity->email,
app/Modules/Identity/PasswordVerification.php
+94
View File
@@ -0,0 +1,94 @@
<?php
declare(strict_types=1);
namespace App\Modules\Identity;
use App\Models\User;
use App\Modules\Identity\Ldap\LdapAuthenticator;
use Illuminate\Auth\SessionGuard;
use Illuminate\Support\Facades\Auth;
/**
* Whether a password is this account's password.
*
* The sibling of SignIn, on the other side of the line it draws. SignIn is
* everything that happens *after* a credential checks out; this is the one
* question asked before it, for the one credential source that has two
* possible homes -- the local hash, or the directory the account was
* provisioned from.
*
* It exists for the reason SignIn gives for existing: "the way they get
* broken is by being written twice". The sign-in form asked this question
* properly, taking a directory bind when the local hash is a placeholder
* nobody holds. The confirm-password screen asked only half of it, and so
* refused every directory account the password it actually has.
*
* The order is the sign-in form's, and matters: the local hash is tried
* first so an account that answers locally never generates directory
* traffic, and an account whose credentials are *known* to live in the
* directory skips the local check entirely, because there the local hash
* is a Str::password(64) placeholder that cannot match anything.
*/
class PasswordVerification
{
public function __construct(private readonly LdapAuthenticator $ldap) {}
public function verify(User $user, string $password): bool
{
if (! $this->ldap->isDirectoryAccount($user)
&& Auth::guard('web')->validate(['email' => $user->email, 'password' => $password])) {
$this->rehashIfStale($user, $password);
return true;
}
$identity = $this->ldap->attempt($user->email, $password, $user);
if ($identity === null) {
return false;
}
$this->ldap->stamp($user, $identity);
return true;
}
/**
* Re-hash a password stored under weaker settings than this
* installation now uses.
*
* Laravel does this inside SessionGuard::attempt(), which neither
* caller uses -- they verify and then hand the account to SignIn,
* which calls Auth::login(). Neither re-hashes, so without this an
* account keeps whatever cost it was created under forever, and
* raising BCRYPT_ROUNDS would quietly apply to new accounts only.
*
* That is not hypothetical: every account the v1 migration carries
* across arrives as `$2y$08$…`, because v1 hashed at cost 8, and would
* otherwise stay four times cheaper to attack than an account created
* here.
*
* **Only ever called on the local branch.** On the directory branch the
* submitted plaintext is the *LDAP* password and the local hash is a
* placeholder nobody holds; writing the directory credential into it
* would mint a second way into the account that keeps working after
* LDAP is switched off.
*/
private function rehashIfStale(User $user, string $password): void
{
$guard = Auth::guard('web');
// getProvider() is on SessionGuard rather than on the StatefulGuard
// contract. This guard is a SessionGuard in every configuration this
// application ships; the check is here so a custom driver degrades
// to "no re-hash" instead of a fatal on the login path.
if (! $guard instanceof SessionGuard) {
return;
}
// No-ops unless the hasher says the stored digest needs it, so this
// costs an already-current account nothing.
$guard->getProvider()->rehashPasswordIfRequired($user, ['password' => $password]);
}
}
app/Modules/Identity/Social/SocialAuthenticator.php
+8 -1
View File
@@ -5,6 +5,7 @@ declare(strict_types=1);
namespace App\Modules\Identity\Social; namespace App\Modules\Identity\Social;
use App\Models\User; use App\Models\User;
use App\Modules\Identity\AccountLookup;
/** /**
* Which local account, if any, a provider identity signs in as. * Which local account, if any, a provider identity signs in as.
@@ -28,6 +29,7 @@ class SocialAuthenticator
{ {
public function __construct( public function __construct(
private readonly SocialProvisioner $provisioner, private readonly SocialProvisioner $provisioner,
private readonly AccountLookup $accounts,
) {} ) {}
public function resolve(SocialSettings $settings, SocialIdentity $identity): SocialResolution public function resolve(SocialSettings $settings, SocialIdentity $identity): SocialResolution
@@ -74,7 +76,12 @@ class SocialAuthenticator
// directory that omits the claim. // directory that omits the claim.
$trusted = $identity->emailVerified || ! $settings->require_verified_email; $trusted = $identity->emailVerified || ! $settings->require_verified_email;
$existing = User::query()->where('email', $identity->email)->first(); // Exactly this address, not whatever the database's collation
// calls equal. utf8mb4_unicode_ci folds accents, so a verified
// sign-in as administrator@éxample.com — a domain somebody else
// can own — selected administrator@example.com and this method
// then linked the attacker's subject to it (GHSA-wgxf-v8cr-37mj).
$existing = $this->accounts->byEmail($identity->email);
if ($existing !== null) { if ($existing !== null) {
// 4/5. The takeover, refused. An unverified address may not // 4/5. The takeover, refused. An unverified address may not
app/Modules/Identity/Social/SocialIdentity.php
+35 -2
View File
@@ -39,8 +39,40 @@ final readonly class SocialIdentity
* | LinkedIn | `email_verified` claim | * | LinkedIn | `email_verified` claim |
* | OpenID Connect | `email_verified` claim, from the ID token | * | OpenID Connect | `email_verified` claim, from the ID token |
* | GitHub | An address at all — Socialite's GithubProvider replaces `email` with the result of `getEmailByToken()`, which only ever returns one that is **primary and verified** | * | GitHub | An address at all — Socialite's GithubProvider replaces `email` with the result of `getEmailByToken()`, which only ever returns one that is **primary and verified** |
* | Microsoft | The token's `tid` matching the configured tenant. Entra does not emit a usable `email_verified`, and its `email` claim is user-mutable — pinning the tenant is what makes it mean anything (this is the *nOAuth* class of bug) | * | Microsoft | The token's `tid` matching the configured tenant **and** `xms_edov` — see below |
* | Facebook | Nothing. The Graph API has no equivalent claim, so an address from Facebook is never treated as verified | * | Facebook | Nothing. The Graph API has no equivalent claim, so an address from Facebook is never treated as verified |
*
* ### Microsoft takes two claims, not one
*
* Entra emits no usable `email_verified`, and its `email` claim is
* user-mutable — populated from `otherMails`/proxyAddresses for a B2B
* guest, among other places. Pinning the tenant was the first answer
* and it is half of one: it defeats the classic cross-tenant *nOAuth*,
* where a stranger's own tenant asserts your address, because a
* foreign tenant carries a different `tid`.
*
* It does nothing about the same attack from *inside* the pinned
* tenant. A colleague, or a guest somebody invited, could shape their
* `email` claim to an administrator's address and have their subject
* bound to that account (GHSA-2rfh-v3j2-2jg7). Tenant-pinning answers
* "which directory said this", never "does this person own that
* address".
*
* `xms_edov` is Microsoft's own answer to the second question — the
* optional claim meaning the tenant has verified it owns the email's
* domain — and their guidance says to require it wherever `email`
* identifies an account. Absent is treated as unverified, which is the
* only safe reading: it is absent by default, so anything else would
* be no check at all.
*
* **What an installation has to do.** The claim must be added to the
* app registration (Token configuration → optional claims → `xms_edov`
* on the ID token). Until it is, Microsoft sign-in still works and
* still creates new accounts — it simply stops silently attaching
* itself to accounts that already exist, and says so, pointing the
* person at signing in with a password and connecting the provider
* from their settings. Accounts already linked are unaffected: they
* resolve by subject, before this is consulted at all.
*/ */
public static function fromSocialite( public static function fromSocialite(
SocialProvider $provider, SocialProvider $provider,
@@ -72,7 +104,8 @@ final readonly class SocialIdentity
|| ($raw['email_verified'] ?? null) === 'true', || ($raw['email_verified'] ?? null) === 'true',
SocialProvider::Github => true, SocialProvider::Github => true,
SocialProvider::Microsoft => is_string($settings->tenant_id) SocialProvider::Microsoft => is_string($settings->tenant_id)
&& ($raw['tid'] ?? null) === $settings->tenant_id, && ($raw['tid'] ?? null) === $settings->tenant_id
&& (($raw['xms_edov'] ?? null) === true || ($raw['xms_edov'] ?? null) === 'true'),
SocialProvider::Facebook => false, SocialProvider::Facebook => false,
}, },
name: is_string($user->getName()) && trim($user->getName()) !== '' name: is_string($user->getName()) && trim($user->getName()) !== ''
app/Modules/Identity/Social/SocialProvisioner.php
+16
View File
@@ -8,6 +8,7 @@ use App\Models\User;
use App\Modules\Audit\Action; use App\Modules\Audit\Action;
use App\Modules\Clients\ClientProvisioning; use App\Modules\Clients\ClientProvisioning;
use App\Modules\Identity\AuthSource; use App\Modules\Identity\AuthSource;
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Str; use Illuminate\Support\Str;
/** /**
@@ -44,6 +45,21 @@ class SocialProvisioner
return null; return null;
} }
// A deleted account still holds its address, and the insert below
// would hit the unique index — a 500 in the middle of a sign-in.
// Refusing here gives the caller the same "there is no account here
// for that address" it gives every other unprovisionable identity,
// which is also all a stranger should learn: whether an address was
// once an account here is not the provider's to publish.
if (! $this->clients->addressIsFree($identity->email)) {
Log::warning('A provider identity was not provisioned: the address belongs to a deleted account.', [
'provider' => $settings->provider->value,
'email' => $identity->email,
]);
return null;
}
return $this->clients->provision( return $this->clients->provision(
name: $identity->name ?? $identity->email, name: $identity->name ?? $identity->email,
email: $identity->email, email: $identity->email,
app/Modules/Identity/TwoFactor/TwoFactorService.php
+10 -9
View File
@@ -62,19 +62,20 @@ class TwoFactorService
$replayKey = "two-factor.used.{$user->id}.".hash('sha256', $code); $replayKey = "two-factor.used.{$user->id}.".hash('sha256', $code);
if (Cache::has($replayKey)) {
return false;
}
if ($this->engine->verifyKey($secret, $code) === false) { if ($this->engine->verifyKey($secret, $code) === false) {
return false; return false;
} }
// A TOTP code is valid for one window either side; block reuse // Claiming the code *is* the answer. Cache::add writes only if the
// for slightly longer than that. // key is absent, so of two requests carrying the same valid code
Cache::put($replayKey, true, now()->addSeconds(90)); // exactly one is told true — where has()-then-put() let both read
// "unused" before either wrote, and a code intercepted once could
return true; // be spent twice inside its window. Same mechanism, and the same
// reason, as the preview log's debounce.
//
// A TOTP code is valid for one window either side; the claim
// outlives that by a little.
return Cache::add($replayKey, true, now()->addSeconds(90));
} }
/** /**
app/Modules/Notifications/Http/Controllers/NotificationPreferencesController.php
+11 -2
View File
@@ -46,13 +46,22 @@ class NotificationPreferencesController extends Controller
$user = $request->user(); $user = $request->user();
assert($user !== null); assert($user !== null);
$keys = $this->emailableKeys();
$validated = $request->validate([ $validated = $request->validate([
'preferences' => ['required', 'array'], // Bounded by the registry, and unique on the type. The
// Rule::in below checks each value; it says nothing about how
// many there are or whether they repeat, and the loop writes
// one row per element. The count comes from the registry
// rather than a literal because the registry is open --
// modules register their own types into it, so a number here
// would be wrong the moment one does.
'preferences' => ['required', 'array', 'max:'.count($keys)],
// Against the registry, not merely "a string": a preference row // Against the registry, not merely "a string": a preference row
// for a type nothing can send is a row that will never be read // for a type nothing can send is a row that will never be read
// again, and the screen only ever offers back what edit() gave // again, and the screen only ever offers back what edit() gave
// it. // it.
'preferences.*.type' => ['required', 'string', Rule::in($this->emailableKeys())], 'preferences.*.type' => ['required', 'string', 'distinct', Rule::in($keys)],
'preferences.*.email_enabled' => ['required', 'boolean'], 'preferences.*.email_enabled' => ['required', 'boolean'],
]); ]);
app/Modules/Platform/Announcements/Events/ResolvingAnnouncement.php
+105
View File
@@ -0,0 +1,105 @@
<?php
declare(strict_types=1);
namespace App\Modules\Platform\Announcements\Events;
/**
* A single message a package wants put in front of staff.
*
* Shown twice, from one source: a band across the top of the dashboard,
* and an icon beside the notification bell that opens the same words on
* every other page. One event rather than two because "the same message"
* is the requirement — two props would drift the day somebody edits one.
*
* Not a widget, on purpose. The widget grid is a closed list of keys that
* dashboard.tsx renders one by one, and each viewer arranges it — so a
* message that matters would sit wherever somebody happened to drag it,
* or under a fold, or switched off. A band above the grid is seen without
* competing with the columns for space.
*
* **Core knows nothing about what it says.** Title, body, the label on the
* button and where the button goes all come from the listener. The first
* caller is the hosted edition telling a free instance what a paid plan
* would give it, which is commercial copy belonging to one offering and
* has no place in the public repository.
*
* One at a time, deliberately. A dashboard that can accumulate banners
* accumulates them, and the second one is what teaches people to skip the
* first. A listener that finds one already set should leave it alone
* rather than overwrite it.
*/
class ResolvingAnnouncement
{
/**
* @var array{title: string, body: string, action_label: string|null, action_url: string|null, tone: string}|null
*/
public ?array $announcement = null;
public function __construct(
/** Whether the viewer is a staff account. */
public readonly bool $isStaff,
) {}
/**
* Audience is declared by the listener and enforced here, rather than
* each listener remembering to check `isStaff`.
*
* The first version of this refused clients outright, which was right
* for the only message that existed — a hosted instance telling its
* administrator about their plan. It stopped being right when a
* message needed to reach the *clients* of a shared instance, and the
* safe way to allow that is not to drop the guard: it is to make
* every caller say who it is talking to, so a listener that forgets
* reaches nobody rather than everybody.
*/
public const AUDIENCE_STAFF = 'staff';
public const AUDIENCE_CLIENTS = 'clients';
/**
* `audience` is required and has no default. A message for staff and
* a message for the people they share with are different messages,
* and a signature that let one be mistaken for the other would put
* the mistake in the quiet direction.
*
* `tone` picks the accent the band is drawn in. Two values, because
* two is what the difference is worth: `info` for something worth
* knowing, `warning` for something worth acting on. Anything else
* falls back to `info` rather than rendering unstyled.
*/
public function show(
string $title,
string $body,
string $audience,
?string $actionLabel = null,
?string $actionUrl = null,
string $tone = 'info',
): void {
if ($this->announcement !== null) {
return;
}
// Silently ignored rather than thrown, and deliberately: a
// listener aimed at the wrong audience should show nothing, not
// break the page it was trying to decorate. An unrecognised value
// reaches nobody for the same reason.
$intended = match ($audience) {
self::AUDIENCE_STAFF => $this->isStaff,
self::AUDIENCE_CLIENTS => ! $this->isStaff,
default => false,
};
if (! $intended) {
return;
}
$this->announcement = [
'title' => $title,
'body' => $body,
'action_label' => $actionLabel,
'action_url' => $actionUrl,
'tone' => in_array($tone, ['info', 'warning'], true) ? $tone : 'info',
];
}
}
app/Modules/Platform/Branding/BrandingServiceProvider.php
+82
View File
@@ -0,0 +1,82 @@
<?php
declare(strict_types=1);
namespace App\Modules\Platform\Branding;
use App\Modules\Api\Events\RegisteringApiModules;
use App\Modules\Files\Thumbnails\Events\RenderingImage;
use App\Modules\Files\Thumbnails\Events\ResolvingImageRendering;
use App\Modules\Platform\Branding\Models\BrandingSetting;
use App\Modules\Platform\Branding\Watermark\ThumbnailWatermarker;
use App\Modules\Platform\Capabilities\Capability;
use App\Modules\Platform\Capabilities\CapabilityRegistry;
use Illuminate\Support\Facades\Event;
use Illuminate\Support\ServiceProvider;
use Inertia\Inertia;
/**
* An installation dressed in its own logo, and a watermark on what its
* clients and visitors see.
*
* Lived in the private cloud-modules package until 2026-08-28, gated
* Cloud-only. That was a fact about where the code had been written
* rather than about who should have it: nothing here needs a hosted
* platform, and a self-hosted installation wanting its own mark on the
* pages it serves is the ordinary case rather than the exotic one.
*
* **What did not move.** Hiding the "Powered by ProjectSend" line is the
* white-label half, and white-labelling is one of the things a hosted
* customer pays for. Its listener still ships only in cloud-modules, so
* an installation without that package has no code able to answer "hide
* it" — flipping an edition variable buys nothing. This module carries
* the column, because it owns the table, and no way to set it.
*
* **What a plan withholds is a separate question.** A free hosted plan
* has branding subtracted from its environment, which the capability
* registry applies; see PROJECTSEND_CAPABILITIES_DISABLED. The row is
* never deleted by that, so a plan that lapses and resumes restores what
* the customer had rather than asking them to build it again.
*/
class BrandingServiceProvider extends ServiceProvider
{
public function boot(): void
{
// Registered unconditionally. The listeners ask whether branding
// is available each time they fire, so an edition change, or a
// plan change that subtracts the capability, takes effect on the
// next request rather than needing a restart.
// Through the module registry rather than routes/api.php, so the
// URL stays /api/v1/modules/branding/* exactly as it was when this
// shipped in a package. A caller's integration does not care which
// repository the code moved to, and moving the path would be a
// breaking change dressed up as a refactor.
Event::listen(RegisteringApiModules::class, function (RegisteringApiModules $event): void {
$event->register(
slug: 'branding',
routes: __DIR__.'/api-routes.php',
capability: Capability::Branding->value,
);
});
Event::listen(RenderingImage::class, [ThumbnailWatermarker::class, 'handle']);
Event::listen(ResolvingImageRendering::class, [ThumbnailWatermarker::class, 'resolve']);
// Gated like the screen that sets it. Without the capability there
// is no branding page to reach, so a row that outlived a gate
// change — a downgraded plan, a restored backup — would put
// somebody's logo on every page of an installation offering no way
// to see it, change it or take it off. Evaluated per request, so
// uploading a logo or changing plan takes effect on the next one.
Inertia::share('branding', fn (): array => [
'logo_url' => $this->available()
? BrandingSetting::query()->first()?->logoUrl()
: null,
]);
}
private function available(): bool
{
return $this->app->make(CapabilityRegistry::class)->has(Capability::Branding);
}
}
app/Modules/Platform/Branding/Http/Controllers/Api/BrandingController.php
+88
View File
@@ -0,0 +1,88 @@
<?php
declare(strict_types=1);
namespace App\Modules\Platform\Branding\Http\Controllers\Api;
use Illuminate\Http\JsonResponse;
use Illuminate\Routing\Controller;
use App\Modules\Platform\Branding\Models\BrandingSetting;
/**
* This installation's branding — its logo and its thumbnail watermark —
* over the host's API.
*
* Read-only on purpose: uploading an image is a multipart flow with
* content-sniffing rules that only make sense with a file picker in front
* of them (see the web controller), and nothing has asked to automate it.
* An integration that wants to render this installation's branding — an
* email builder, a status page — only needs to read it.
*
* This controller knows nothing about authentication, rate limiting,
* error formats or which edition it is running in. The host supplies all
* of that: the module is registered through RegisteringApiModules, which
* mounts these routes inside the API's own auth stack and behind
* `capability:branding.customize`. That is the whole point of the seam —
* a package declares paths and controllers, and nothing else.
*/
class BrandingController extends Controller
{
/**
* Get this installation's logo.
*
* Returns a null `logo_url` when no logo has been uploaded, which is
* the normal state rather than an error.
*/
public function show(): JsonResponse
{
$setting = BrandingSetting::query()->first();
return response()->json([
'data' => [
'logo_url' => $setting?->logoUrl(),
'updated_at' => $setting?->updated_at?->toIso8601String(),
],
]);
}
/**
* Get the watermark applied to this installation's rendered images.
*
* Applies to the thumbnails and previews clients and anonymous
* public visitors see; what this installation's own staff see is
* never marked. The stored files, and every download of them, are
* never altered either way.
*
* `enabled` is false whenever no watermark is being drawn, including
* when the toggle is on but its image has since been removed —
* it answers "is this installation watermarking?", not "which way is
* the switch pointing?". `position` is one of `top-left`,
* `top-center`, `top-right`, `middle-left`, `center`, `middle-right`,
* `bottom-left`, `bottom-center`, `bottom-right`; `size` is the
* percentage of the image the mark is fitted into, and `opacity`
* a percentage.
*
* Read-only, same as the logo: an integration rendering its own
* derivative images can reproduce the mark, but uploading one is a
* multipart flow with content-sniffing rules that only make sense
* behind a file picker.
*/
public function watermark(): JsonResponse
{
// Falls back to an unsaved instance so an installation that has
// never opened the branding screen answers with the defaults it
// would start from, rather than a payload of nulls a caller would
// have to invent its own meaning for.
$setting = BrandingSetting::query()->first() ?? new BrandingSetting;
return response()->json([
'data' => [
'enabled' => $setting->watermarksThumbnails(),
'image_url' => $setting->watermarkUrl(),
'position' => $setting->watermark_position->value,
'size' => $setting->watermark_size,
'opacity' => $setting->watermark_opacity,
],
]);
}
}
app/Modules/Platform/Branding/Http/Controllers/BrandingController.php
+258
View File
@@ -0,0 +1,258 @@
<?php
declare(strict_types=1);
namespace App\Modules\Platform\Branding\Http\Controllers;
use Illuminate\Http\RedirectResponse;
use App\Modules\Files\Thumbnails\Events\ImageRenderingChanged;
use Illuminate\Http\Request;
use Illuminate\Http\UploadedFile;
use Illuminate\Routing\Controller;
use Illuminate\Support\Facades\Event;
use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Str;
use Illuminate\Validation\Rule;
use Inertia\Inertia;
use Inertia\Response;
use App\Modules\Platform\Branding\Models\BrandingSetting;
use App\Modules\Platform\Branding\Watermark\WatermarkPosition;
use App\Modules\Platform\Branding\Watermark\WatermarkSample;
use RuntimeException;
use Symfony\Component\HttpFoundation\Response as SymfonyResponse;
/**
* Two site-wide pieces of artwork: the logo shown in the sidebar in
* place of the default icon, and the mark stamped onto the thumbnails
* and previews clients and public visitors see. Every route here is gated end-to-end by the host's
* `capability:branding.customize` middleware (see routes.php) — this
* module has no idea what edition it's running in, it just trusts the
* gate.
*/
class BrandingController extends Controller
{
public function edit(): Response
{
// An unsaved instance rather than `current()`: rendering a settings
// screen must not write a row, and the model carries the same
// defaults the table does (see its $attributes) so the form starts
// on the values a first save would produce.
$setting = BrandingSetting::query()->first() ?? new BrandingSetting;
return Inertia::render('branding/edit', [
'logo_url' => $setting->logoUrl(),
// Read, never written here. Hiding attribution is the
// white-label half and stays a hosted feature: the switch is
// rendered only where Capability::AttributionHide is held, and
// the route that saves it is registered by cloud-modules. Core
// carries the column because it owns the table, and carries no
// way to set it.
'hide_attribution' => $setting->hide_attribution,
'watermark' => [
'enabled' => $setting->watermark_enabled,
'image_url' => $setting->watermarkUrl(),
'position' => $setting->watermark_position->value,
'size' => $setting->watermark_size,
'opacity' => $setting->watermark_opacity,
],
'watermark_positions' => WatermarkPosition::values(),
]);
}
public function store(Request $request): RedirectResponse
{
$validated = $request->validate([
'logo' => ['required', 'image', 'max:2048'],
]);
/** @var UploadedFile $upload */
$upload = $validated['logo'];
$setting = BrandingSetting::current();
if ($setting->logo_path !== null) {
Storage::disk('public')->delete($setting->logo_path);
}
$setting->update(['logo_path' => $this->storeImage($upload)]);
return back()->with('success', __('Logo updated.'));
}
public function destroy(): RedirectResponse
{
$setting = BrandingSetting::query()->first();
if ($setting?->logo_path !== null) {
Storage::disk('public')->delete($setting->logo_path);
$setting->update(['logo_path' => null]);
}
return back()->with('success', __('Logo removed.'));
}
/**
* Save the whole watermark form at once — toggle, artwork, placement,
* scale and opacity. One endpoint rather than one per field because
* they are only meaningful together: turning it on without an image,
* or changing the size without seeing the position, are not states
* worth being able to save.
*/
public function updateWatermark(Request $request): RedirectResponse
{
$setting = BrandingSetting::current();
$validated = $request->validate([
// The image is optional on every save *except* the one that
// turns watermarking on with nothing stored yet — otherwise
// adjusting the opacity would mean re-picking the file each
// time. `exclude_if` keeps the rule off the payload entirely
// rather than requiring a re-upload.
'image' => [
$setting->watermark_path === null && $request->boolean('enabled') ? 'required' : 'nullable',
'image',
'max:2048',
],
'enabled' => ['required', 'boolean'],
'position' => ['required', Rule::in(WatermarkPosition::values())],
'size' => ['required', 'integer', 'min:5', 'max:100'],
'opacity' => ['required', 'integer', 'min:1', 'max:100'],
], [
'image.required' => __('Choose the image to use as the watermark.'),
]);
$attributes = [
'watermark_enabled' => (bool) $validated['enabled'],
'watermark_position' => $validated['position'],
'watermark_size' => (int) $validated['size'],
'watermark_opacity' => (int) $validated['opacity'],
];
if (($validated['image'] ?? null) instanceof UploadedFile) {
if ($setting->watermark_path !== null) {
Storage::disk('public')->delete($setting->watermark_path);
}
$attributes['watermark_path'] = $this->storeImage($validated['image']);
}
$setting->update($attributes);
$this->forgetRenderedImages();
return back()->with('success', __('Watermark settings saved.'));
}
/**
* A stand-in photograph with the mark drawn on it, so the settings
* screen can show what a client will actually see. Staff surfaces are
* never watermarked, so without this an administrator has no way to
* judge their own settings short of signing in as a client.
*
* Takes placement, scale and opacity from the *query string* rather
* than from the saved row: the point is to answer "what would this
* look like" while the form is still being adjusted. The artwork
* itself has to be the stored one — an unsaved file lives in the
* browser, not on this server — which is why the screen tells you to
* save after choosing a new image.
*
* Drawn by the same WatermarkPainter that renders the real thing, so
* the sample cannot flatter the settings.
*/
public function watermarkSample(Request $request, WatermarkSample $sample): SymfonyResponse
{
$setting = BrandingSetting::query()->first();
$markPath = $setting?->watermark_path;
// Not 404 for "you have not uploaded one yet" — the screen asks for
// this image before there is anything to draw, and a broken <img>
// is a worse answer than none. It hides the sample instead.
abort_if($markPath === null || ! Storage::disk('public')->exists($markPath), 404);
$validated = $request->validate([
'position' => ['required', Rule::in(WatermarkPosition::values())],
'size' => ['required', 'integer', 'min:5', 'max:100'],
'opacity' => ['required', 'integer', 'min:1', 'max:100'],
]);
$image = $sample->render(
Storage::disk('public')->path($markPath),
WatermarkPosition::from($validated['position']),
(int) $validated['size'],
(int) $validated['opacity'],
);
return new SymfonyResponse($image->toString('image/png'), 200, [
'Content-Type' => 'image/png',
// Every request has different parameters and the artwork behind
// it can be replaced at any moment; a cached sample would show
// an administrator the settings they had a minute ago.
'Cache-Control' => 'no-store, max-age=0',
]);
}
/**
* Drop the artwork and switch watermarking off with it — an "enabled"
* that no image backs is not a state this screen can leave behind.
*/
public function destroyWatermark(): RedirectResponse
{
$setting = BrandingSetting::query()->first();
if ($setting === null) {
return back();
}
if ($setting->watermark_path !== null) {
Storage::disk('public')->delete($setting->watermark_path);
}
$setting->update([
'watermark_path' => null,
'watermark_enabled' => false,
]);
$this->forgetRenderedImages();
return back()->with('success', __('Watermark removed.'));
}
/**
* The host caches every image it renders and never revisits it, so
* without this a settings change would only reach files nobody has
* looked at yet.
*
* Dispatched by *string* class name: the host's event class cannot be
* constructed from here (this package builds with no host present),
* and it carries no payload precisely so that it doesn't have to be.
* With no host listening this is an inert no-op.
*/
private function forgetRenderedImages(): void
{
Event::dispatch(new ImageRenderingChanged);
}
/**
* The extension comes from the *content*, never from the uploaded
* filename. This disk is web-served (public/storage is symlinked into
* the document root and nginx serves it as a static file), and the
* `image` rule only inspects the sniffed content — so a GIF whose
* filename says ".html" passes validation and would then be stored,
* and served back, as text/html: stored XSS on this app's own origin,
* from any account that can reach this page. guessExtension() is
* derived from the same sniffed mime type the validator just
* accepted, so the two can no longer disagree.
*/
private function storeImage(UploadedFile $upload): string
{
$extension = $upload->guessExtension() ?? 'bin';
$path = $upload->storeAs('branding', Str::uuid().'.'.$extension, 'public');
if ($path === false) {
throw new RuntimeException('Could not store the uploaded image.');
}
return $path;
}
}
app/Modules/Platform/Branding/Models/BrandingSetting.php
+89
View File
@@ -0,0 +1,89 @@
<?php
declare(strict_types=1);
namespace App\Modules\Platform\Branding\Models;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Facades\Storage;
use App\Modules\Platform\Branding\Watermark\WatermarkPosition;
/**
* A single-row settings table — see the migration's comment for why no
* tenant/owner column is needed.
*
* @property int $id
* @property string|null $logo_path
* @property bool $watermark_enabled
* @property string|null $watermark_path
* @property WatermarkPosition $watermark_position
* @property int $watermark_size
* @property int $watermark_opacity
* @property bool $hide_attribution
* @property \Illuminate\Support\Carbon|null $created_at
* @property \Illuminate\Support\Carbon|null $updated_at
*/
class BrandingSetting extends Model
{
protected $table = 'branding_settings';
protected $guarded = [];
protected $casts = [
'watermark_enabled' => 'boolean',
'watermark_position' => WatermarkPosition::class,
'watermark_size' => 'integer',
'watermark_opacity' => 'integer',
'hide_attribution' => 'boolean',
];
/**
* Mirrors the migration's column defaults, so an unsaved instance
* answers the same as a freshly created row would. That is what lets
* the settings screen render `new BrandingSetting` on an install that
* has never touched branding, instead of either creating a row on a
* GET or restating these numbers a second time in the controller.
*/
protected $attributes = [
'watermark_enabled' => false,
'watermark_position' => 'bottom-right',
'watermark_size' => 30,
'watermark_opacity' => 60,
'hide_attribution' => false,
];
public static function current(): self
{
return static::query()->firstOrCreate([]);
}
public function logoUrl(): ?string
{
return $this->logo_path === null ? null : Storage::disk('public')->url($this->logo_path);
}
public function watermarkUrl(): ?string
{
return $this->watermark_path === null ? null : Storage::disk('public')->url($this->watermark_path);
}
/**
* The artwork to stamp on a thumbnail being rendered right now, or
* null when this installation is not watermarking.
*
* Phrased as "which image, if any" rather than as a boolean because
* the toggle alone is not enough to act on: removing the image
* leaves the toggle standing, and a row restored from a backup can
* carry an `enabled` that its file no longer backs. Answering both
* halves at once means a caller cannot check one and use the other.
*/
public function activeWatermarkPath(): ?string
{
return $this->watermark_enabled ? $this->watermark_path : null;
}
public function watermarksThumbnails(): bool
{
return $this->activeWatermarkPath() !== null;
}
}

Some files were not shown because too many files have changed in this diff Show More