Public vs Private Paths

Files in ActiveManage live in one of two kinds of path — public (directly accessible by URL) or private (only accessible through an authenticated endpoint). Choosing right is the difference between a fast CDN-served asset and a leak of confidential records.

Public Paths

• Served directly from a CDN or static-file host.
• No authentication required — anyone with the URL can fetch.
• Fast (geographic edge caching).
• URL is essentially permanent.

Use for: product images, marketing assets, public profile photos, downloadable brochures, anything you'd happily share with the world.

Private Paths

• Served through fetchfile.php (or a signed-URL handler) which checks the requesting user's permissions before delivering bytes.
• Bytes never leak — every fetch goes through authentication.
• Slightly slower (no CDN edge caching) but acceptable for record attachments.
• URLs include a short-lived token; old URLs stop working.

Use for: customer document uploads, invoices, contracts, internal reports, medical records, anything sensitive.

Choosing the Right One

• Default new file fields to private. Promote to public only when you've thought about it.
• Per-field setting in the datastore configuration controls which path applies to uploads in that field.
• Audit existing public paths annually — sensitive material can drift into the wrong place over time.

Worked Examples

• Product catalogue: Public — product photos served from CDN.
• Order invoices: Private — only the order's buyer and admins can fetch.
• Marketing PDFs: Public — lead-magnets visible to anyone.
• HR documents: Private — only HR and the employee themselves can fetch.
• User avatars: Public — efficient and visible to all logged-in users.

Warning: Moving a file from public to private invalidates existing public URLs. Coordinate any such move with whoever might have linked to the file.

fetchfile.php is the authenticated file-serving endpoint that gates access to every file stored in a private path. It checks who's asking, what they want, whether they're allowed to have it, and then streams the bytes (or refuses).

How It Works

1. Request hits /fetchfile.php?id=<file-id>&token=<short-lived>.
2. Server validates the token (signature + expiry).
3. Server looks up the file record. If linked to a parent record, server checks the user can see the parent.
4. Server fetches bytes (from S3, local disk, or wherever the file store points).
5. Server streams the response with the right Content-Type and a Content-Disposition that triggers display or download as appropriate.
6. Access logged.

Security Properties

• No direct URL access: Even if someone learns the underlying storage path, they can't fetch it directly.
• Permission inheritance: If you can't see the order, you can't see its attached invoice.
• Token expiry: URLs included in emails expire after 24 hours; share-with-others URLs can be set shorter.
• Audit trail: Every fetch is logged with user, file and IP.

Performance Tuning

• Enable byte-range support so video players can seek.
• Use signed S3 URLs for large files (handoff the streaming to S3 directly while still doing auth on the way in).
• Cache permission lookups for hot files within a request to avoid repeat queries.

Worked Examples

• Patient record access: Doctor opens patient record; PDF reports linked. Clicking a PDF goes through fetchfile.php — confirms the doctor has access to the patient, then streams.
• Order invoice link: Order confirmation email contains a fetchfile URL with a 7-day token. After 7 days the customer signs in normally to see invoices.
• Embedded video: Internal training portal uses fetchfile-served videos; player byte-range support lets users skip to chapters efficiently.