S3 upload provider plugin with both public and private assets

Questions and Answers
1

Hello there!

Today, I’ve been exploring the option of having a Strapi instance for a new project with both public and private assets.

Let’s imagine that one part of the collections and single types from Strapi (Part A) controls the public content of a website (therefore all the images/assets from this part should be publicly available on public URLs). Then part B (different collections) controls internal files that should not have public URLs available.

My question then is: How could I manage these two types of assets?

The assets for part A should not need to have signed URLs as these will be used for a static site generated website (therefore the file URLs should always be publicly available). Part B instead should have signed asset URLs with the default options from the S3 plugin for private buckets.

I’m pretty sure this is a common situation many products can face and hope there’s a solution for this!

2 Likes
2

At present, we are using two distinct Strapi installations to separate private content from public content.

3

Thank you for your reply Sam!

How’s that working for you? Seems like a pretty drastic solution.

Best,

4

Initial Steps

We started by extending the plug-in to store images in folders, facilitating faster S3 searches (we manage a substantial number of images) a simple code to add folders support.

Security Implementation

Next, we attempted to add a secure and non-secure flag. However, upon realizing that version 5 was imminent, we paused this project.

Media Management Strategy

We believe that media needs to maintain both secure and unsecured states.

Additionally, it should include metadata such as license details for images downloaded from image banks. These should be organized into subfolders for long-term maintenance.

Transition to Strapi

The switch to use two Strapi’s public and secure media required a different maintenance approach. Instead of using the default media, we implemented a custom UI for secure and regular media, ensuring uniformity in our codebase that store also the licenses details if the images are from image bank.

Conclusions

Strapi’s media management requires significant enhancements to support secure and non-secure states, additional metadata, and various predefined sizes for content delivery.

If Strapi changes the media module to a plug-in instead of being built into the admin interface, it will be easier to expand. This would allow for direct connections to image banks for CMS use.

Currently, we use a Next.js backend to handle all the work, storing metadata in custom components.

We had to drop the used of media in strapi as its not allow to pull images from different locations secure & none secure.

Touch of a Personal Opinion: To truly fulfill its role as a headless CMS, Strapi needs a way to extend its media functionality, akin to how it handles user collections. This would greatly enhance its flexibility and usability.

1 Like