The discussion revolves around the need to prevent anonymous users from accessing image and file URLs on invitation-only Discourse forums, especially for communities handling sensitive content. While a setting exists to prevent anonymous file downloads, users advocate for a similar global flag for all uploads. The main challenge is balancing privacy with performance, as enforcing authentication for images would eliminate CDN benefits and require all requests to route through the app. Some users suggest using a middleware like nginx with authentication, but others prefer a built-in solution. A plugin, Discourse Images Guardian, was developed to address this, though it has faced compatibility issues with newer Discourse versions. The plugin has been updated to work with the latest beta, but issues remain. A new “secure media” feature is being tested for self-hosted instances with S3 uploads, which will restrict access to media via a server endpoint and replace media in emails with login prompts. However, this approach also removes CDN support and may impact performance on large forums. Some users request additional protection for avatar icons, and the plugin developer has committed to addressing compatibility issues. The first post outlines the initial request, while chrisc and martin provide key insights into the challenges and solutions.
… some internal communities deal in such sensitive information that outright disallowing any viewing of these images would be preferable. We do already have a setting for prevent anons from downloading files, so the suggestion is to have something similar, but as a global flag for all images & other uploads.
Giving up on CDN is a perfectly viable solution in such a case though, since communities under complete lock-down would never surpass a few thousand users and will never see crazy spikes in traffic.
I am trying to push Discourse as our new forum software (coming from vBulletin), but this might be considered a blocker by the other members.
We deal with very sensitive and personal content, and I believe the idea that an image can potentially be viewed by anyone on the web will scare some of them. Privacy is the #1 concern.
I have hit exactly the same issue as @jrgen highlighted and fear that the only option might be to delete all the images transferred from vBulletin and then make it very clear to people that they should only use images for their profile and background that they are happy being potentially publicly associated with their username. Because profile images have URLs like this: https://forum.example.org/user_avatar/forum.example.org/chrisc/120/26_1.png (background image URLs are not so bad since they contain a random string).
For one client I setup a Discourse server behind a HTTPS only Ngnix reverse proxy with HTTP Authentication to prevent data leaks of this nature, technically it worked fine, however the usability issues raised by the need for people to enter two usernames and passwords was far too much for non-technical users to cope with so for this reason Discourse was unusable for this job.
Deleting or not allowing images isn’t really practical either — the only workable solution to this is for there to be a settings tick box, for images, as suggested in the first post in this thread:
We do already have a setting for prevent anons from downloading files, so the suggestion is to have something similar, but as a global flag for all images & other uploads.
We would like to tackle this problem, and have a setting that forces all images and attachments to require a login to view. I think it is a completely valid use case. It is kind of difficult, though. If you wanted to work on it we could fund that work.
Using such a middleware has the additional benefit of being able to track and trace and log access to sensitive assets, count such access, and run statistics on requests!
EDIT: And you can then fine-tune the access permissions by user, or allow only users that can view the post(s) linking to the asset to download it.
The bad thing is… probably a custom nginx need to be built. That would probably complicate the setup, so this shouldn’t be something that comes as default, right?
