An additional storage option that used S3 for image / attachment storage like the existing s3 option does, with the addition of causing the application itself to pull images from S3 and serve them to clients directly would be hugely helpful.
An alternative way to explain this is that an option like this would cause BookStack to treat images, the way it treats attachments stored in S3 now.
Describe the benefits this would bring to existing BookStack users
This would allow users to use S3 storage for BookStack without needing to allow public access to the bucket itself.
This would allow users who wish to restrict access to BookStack (and images used in BookStack) by source IP address a viable way to do that, without having to build out complicated infrastructure to also restrict access to the images hosted in S3.
This would allow users who wish to run the containerized version on a hyper-scale cloud provider where volume mounts don't currently appears to work well with BookStack a great way to do that.
Can the goal of this request already be achieved via other means?
Yes - The signed URL approach mentioned in #763 would be a potentially viable alternative. However, given the way BookStack already pulls attachments from S3, this approach might be easier to implement.
Have you searched for an existing open/closed issue?
[X] I have searched for existing issues and none cover my fundamental request
How long have you been using BookStack?
Under 3 months
Additional context
I have been asked to deploy BookStack for an organization that requires a high level of security. The organization wishes to deploy this in containerized form as it does with it's other applications. We attempted to deploy the LinuxServer.io containers on Google Cloud Platform (Cloud Run) using an attached Cloud Storage volume with the storage option set to local_secure. We ran into the exact same errors mentioned in #4226. We expect this is caused by the way the mounted object storage appears to the container. Thanks for your consideration.
Describe the feature you'd like
An additional storage option that used S3 for image / attachment storage like the existing s3 option does, with the addition of causing the application itself to pull images from S3 and serve them to clients directly would be hugely helpful.
An alternative way to explain this is that an option like this would cause BookStack to treat images, the way it treats attachments stored in S3 now.
Reference: Current Storage Options
Describe the benefits this would bring to existing BookStack users
Can the goal of this request already be achieved via other means?
Yes - The signed URL approach mentioned in #763 would be a potentially viable alternative. However, given the way BookStack already pulls attachments from S3, this approach might be easier to implement.
Have you searched for an existing open/closed issue?
How long have you been using BookStack?
Under 3 months
Additional context
I have been asked to deploy BookStack for an organization that requires a high level of security. The organization wishes to deploy this in containerized form as it does with it's other applications. We attempted to deploy the LinuxServer.io containers on Google Cloud Platform (Cloud Run) using an attached Cloud Storage volume with the storage option set to local_secure. We ran into the exact same errors mentioned in #4226. We expect this is caused by the way the mounted object storage appears to the container. Thanks for your consideration.