AttachmentDelivery

Corex\Security\Upload\AttachmentDelivery · class · Core layer

The only way to read a file stored by {@see AttachmentStore} (spec 081, FR-009 / FR-015). The file lives outside anything the web server should serve, so it has no working public URL — this route is how an authorised operator opens it. That inversion is the design: the check happens before a byte is read, in PHP, on every request, rather than depending on a .htaccess the server may or may not honour. Two things it deliberately does not do: - No signed URLs with an expiry. A signed URL is a bearer token in a browser history, a referrer header and an email forward. The viewer is already logged in; asking who they are is cheaper and does not leak. - No X-Sendfile/X-Accel-Redirect. Both are faster and both hand the file back to the web server’s configuration — the thing this class exists because CoreX cannot verify.

Public API

register(): void

url(int $attachmentId): string

The address an authorised viewer opens.

serve(): void

deliver(int $attachmentId): never

Send a protected file to the person asking, whom the caller has found may read it. The one place a protected file leaves from. {@see serve()} asks WordPress whether this person may read the attachment. A file that belongs to something with a rule of its own (a submission, which has the inbox’s) is checked by that rule and then sent from here, so what is sent, and under which headers, is decided once.