Guarded Static Assets

[Silic0nS0ldier]

In an authenticated system there is often a need to serve static assets/content that not all audiences should have access to. Not all scenarios have identical requirements, however from a technical standpoint there is a significant degree of overlap.

The common problems to solve for are;

• Ensuring a high level of performance (as close to standard static file serving as possible)
• Scaling (static assets are typically numerous, and will more easily overwhelm the server)
• Maximising code reuse (currently everyone has to invent their own solution)
• Quick to implement (a quick implementation currently means forgoing performance and scaling issues)

[lcharette]

Could a special route guard be enough? I feel it’s one of those rare case scenario that could easily be fixed with the dev adding a custom route for the assets. Said asset would then only be needed to be backlisted from the default asset route?

how would protected assets in the public folder be adressed in production?

[alexweissman]

In the past I've seen this implemented on FB and other platforms with a temporary copy of the asset in question that expires after a certain time period. Coupled with a long, unguessable filename, it's effectively inaccessible to anyone without the link. I.e. knowledge of the URL functions as a one-time temporary access token.