File attachments in restricted categories should be restricted

Currently, files that are uploaded to a restricted category are accessible to anyone, even users who are not logged in. Chances are that these files get indexed by search engines and thus become public. I agree with @tobiaseigen that this is quite a serious issue:

But I am not sure what exactly the current state of affairs is regarding this, except that, some time ago, @dmitry_fedyuk created the restrict files plugin whose latest version seems to be 2.1 which is confirmed to be compatible with discourse v1.7.0.beta9.

I would like to ask conference participants to upload their papers as attachments on my forum but I cannot do this unless I know that only users with access to the specified category can access the uploaded papers.

So my question to @dmitry_fedyuk is: can you confirm that the current version is compatible with discourse v1.8.0.beta10? I would also be curious to hear about any user experiences with the plugin.

This is something I want core to support out of the box, but it would require a fair bit of internal change.

That said, I don’t think the current state of affairs is terrible, the actual links to the assets contain “secure random” strings, they are not guessable.

Sure, if someone with access shares a link to it then someone unauthorized can download.


What if someone with access downloads the paper and then forwards it via email?


Correct me if I’m wrong: but what good are those random links if they are indexed by google?

Maybe I should just save all the papers to /dev/nulljust to be save? LOL
But seriously (if this is of any concern here): the default mode of distributing work-in-progress papers at (academic) conferences and workshops is that all authors send their paper to the convenor who then circulates them to the registered participants (or whatever was agreed with the authors).

So I’d say that is the security standard to measure this specific use-case against, i.e. the original recipients are by default trusted to not circulate the paper any further, let alone to make it available online. So the question is: what additional threats am I introducing by distributing the papers via the forum? One is the risk of (unintended) online publication via search engines (see above). Another, much smaller one, is the accidental forwarding of the link to wherever due to the fact that some users will not be aware of the link being secret (e.g. when forwarding an email in which they were notified about the topic with the link). Finally, there is perhaps also a small risk of discourse leaking the link for whatever reason (this is something I cannot assess myself).

That is great news! Will this protect content retrospectively?

Hm, should I read this as saying that the existing plugin is not doing a good job?

Most likely yes.

The plugin you mentioned is different in that it’s adding a paywall.
We just want to prevent the download when you don’t have the permission to.

How? this is a secure category, Google only has access to public categories. Google can not see this content or links.


No, the above mentioned restrict files plugin only restricts file access. At least the author states that

The «Restricted Files» plugin allows you to restrict access to downloads (attached files) so only users of permitted groups can download files from your Discourse forum. (…) To receive payments from your customers you can use my another Discourse plugin «PayPal Buy Now»

It is highly unlikely we will work on this until a large paying customer asks for it.


Okay, that’s good to know. I was not sure, how discourse treats robots.

So, to conclude, we can say that attachments on discourse are as safe as a Google document with a privately shared link, right?

But what is the issue with the restrict files plugin?

Yes, that is the case.

I have no idea, I did not write it or review it

1 Like

I asked because you said it would require a fair bit of work to implement the apps functionality into core. Which I hear as saying: the plugin is not something we can use in core.