Building a member area on Core dna: who a member is in the data, the sign-in flows and their templates, single sign-on and passkeys, the my-account routing convention, members-only content, sessions and the page cache, and the security checks to run before launch.
L2
Unit 05 · Members-only content
Members-only files
Members-only contentPage 30 of 36Updated
Every file in the file manager is served to anyone who has its URL, whatever page links to it. What that means for a members-only page, the settings that look like protection and are not, and the options for a file that must stay private.
Who this is for. Anyone about to promise a client "members-only downloads". Afterwards you can say exactly how private each option is, and choose one before launch rather than after a leak.
Every file is public
The route that serves /files/… makes no checks at all: not whether anyone is signed in, not their group, not the permissions of the record that links to the file, not the page around it. Anyone with the URL gets the file. And the URL travels: it is in the page source for every member who can open the page, in their browser history, and in every email or chat they paste it into.
So a members-only page that links a PDF protects the page, not the PDF.
What looks like protection and is not
The page's permissions. They decide who can open the page. The file is fetched by its own URL, which they do not cover.
A file's hidden flag and expiry date. They belong to the admin's file manager, which uses them to filter its list. Neither is checked when the file is served.
Sharing a file with a user in the file manager. It gives another admin user access in the manager, and nothing on the site.
The environment's file permissions setting. It changes whether the file route reads the visitor's session, not who receives the file.
robots.txt and noindex. They ask search engines not to list a file. People still get it.
Check before you promise
Copy a file link from a gated page and open it in a private window. If it downloads, it is public, and every member, and everyone they share it with, can download it too.
What to do instead
Choose by what a leak would cost the client, and tell them which one they are getting:
Option
How private
Suits
Put the material in the page itself, as rich text or layout areas
Text, tables, short documents that do not need to be a download
Upload the file under a long, random name and link it only from the gated page
Obscurity, not access control: anyone given the link has the file, for as long as it exists
Material whose leak would be awkward, not harmful
Keep the file off the platform, in storage that issues short-lived signed links, handed out by something that checks the member first
Real access control: the link works for minutes, and only a member who passed the check gets one
Anything that matters: paid material, client documents, personal data
The last option needs a small piece of server-side work that you own: an integration, or a synchronous job endpoint, that takes the signed-in member's request, checks their group or entitlement (Entitlements: access per record), asks the storage service for a signed link and answers with it. The gated page links to that endpoint, never to the file. Media and files describes the file manager's side of the same choice.
Files members send you
The same applies the other way. A file a member uploads through a form is stored in the file manager and served at a /files/ URL like any other, so anyone who learns the URL can download it. Do not collect documents through a form that you would not publish; File uploads covers the alternatives.