Download attachments and whitelist/blacklist strategy

Hi everyone,

we got recently a bug report ( about using the configuration to force downloading an attachment, in case of an attachment added by a PR user. Following this issue, I proposed a first PR with a new behaviour but after discussing it with @tmortagne (discussion started there:!$ it appeared that:

  1. the reported bug is right now an expected behaviour
  2. we need to decide if it’s a behaviour we still want
  3. we need to decide how to improve it to fix the “bug”

So, right now the behaviour of downloading attachment is the following:

  1. if the attachment has been added by a user with PR (Programming Rights), the attachment is always displayed inline.
  2. if the attachment has been added by someone without PR, and a configuration is given for and no configuration is given for then the mimetype of the attachment is checked against the mimetype list of this blacklist to define if it should be downloaded or displayed inline (if present in blacklist, it won’t be displayed inline)
  3. in other cases, the mimetype of the attachment is checked against the mimetype list defined in this one might be the default whitelist or a custom one.

Note that this behaviour is currently partially explained in (partially because it doesn’t explain in which condition the blacklist should be used).
Note 2: It’s always possible to use a force-download request parameter to override the mentioned behaviour and force the download, I won’t mention it anymore here since this proposal is about the default behaviour without specific parameters.

So the problem with the current behaviour, and the bug reported in XWIKI-17754 is that right now the attachments can never be forced to be downloaded by default if they have been added by a PR user. My first proposal to overcome this issue was to change the way we resolve this, by checking first the blacklist, before checking if the attachment was added with PR or not.
As indicated in my first PR, the resolution was then the following:

The problem with that solution is that it could break compatibility of some configurations: we couldn’t handle usecase where a wiki is configured to allow only PR users to display images attachments inline. If you have blacklisted some mimetypes thinking “it’s only for normal users” you’ll be hit by the change.
A way to overcome this, would be to introduce a new boolean configuration, to basically say “use the old mechanism”.

Now @tmortagne proposed another solution, which would be to introduce a new list of mimetypes, for attachments “forced to be downloaded”: this list would be taken into account before the actual mechanism and would allow to force downloading attachments based on mimetype, even if added by PR users.

AFAICS there is no scenario (based on mimetype) that we couldn’t support. The only problem I can think of with this solution is that it makes the configuration for mimetypes of attachment a bit more difficult to understand with 3 different lists. Now Thomas mentioned that we could move the existing configuration lists to a “Security” section since those are about protecting against XSS, and put the new configuration in a “Attachment” section, since it’s only about usability.


I vote for this one :slight_smile:

It’s a lot safer in term of retro compatibility (especially since we are talking about security here) and once you moved the security stuff in another section I find it much easier to use when all you want is to indicate some types that should always be downloaded instead of opened (the default when supported by the browser).

FTR, I don’t really understand this logic. I don’t see why someone with PR would not be able to get a download instead of inline where it makes sense.

EDIT: I also agree that changing that would break backward compat. Just don’t know how important it is.

I’ll trust you guys. Just seems like we’ll have a lot of config params and thus it may be complex to use them. Maybe it’s worth legacifying some to keep it simple.

Well the latest proposal involve to add one new configuration parameter for it, but it’s doesn’t replace even partially the two other existing ones: the new one is about usability where the 2 others are about security. So we cannot really legacify any of them.

It seems to me there would be 3 configs:

  • “forced to be downloaded”

And you said:

about using the configuration to force downloading an attachment

So is also about forcing to download an attachment, same as “forced to be downloaded”, hence the confusion for users.

What’s the proposed new config name?

TBD :slight_smile:

Yes, 3 total, but only 1 new.

Here’s what I wrote about it:

There is a bit of an overlap, but that can be documented. Basically the blacklist would be for all attachments not added by a PR user (same for whitelist), and it’s the current behaviour: those are security properties for attachment pushed by people without PR rights.
Now the new property will be about the attachments types that should be always download and not displayed inline, not matter what is the security configuration: it’s not about security, just about a behaviour we want in the UI.

I still don’t get the use case for PR…

So you mean deprecating the 2 existing properties and changing the config names to be prefixed with “security” and moved under ?

Imagine a wiki configured to blacklist images mimetypes: right now it still allow to display attached images in wiki pages. If you change the behaviour of DownloadAction it won’t be the case anymore.
Knowing that any attachment we put in XWiki Standard is made with superadmin which by definition has PR rights, it could break all distribution to change it now.

Not sure we’d need to deprecate their name here since we wouldn’t change their behaviour. We could but I don’t think it’s mandatory. Now yes I think we should move them in the security section.

I’m really -0 and maybe even -1 for that. We shouldn’t use invalid config names for sections, that’s starting a bad trend and is even more confusing. There are other configs that are in extensions or other modules that are related to security, yet they should remain under these other prefixes.

We’d also need to decide if if makes sense to be security.* or if it better to be*.

I must be missing some knowledge. What does blacklisting the image mimetypes mean? For me it means forcing to download these image attachments when you click on them vs displaying them inline.

What does this have to do with PR? What is the security need?


Ok so let’s keep them where they are now then. They are definitely related to attachment, we can provide more documentation to properly distinguish them for the new one to add.

I really wouldn’t change their name since those are already used configurations, and the behaviour wouldn’t change.


I was just taking an example with images because we have in XS attached images with superadmin who has PR by definition. I was trying to illustrate that changing the behaviour of the existing configurations would change the behaviour of interacting with those images with DownloadAction, which could be potentially a breaking change.
Let’s be a bit more explicit: right now we are checking first if the user who attach the files has PR or not, and then only we check for blacklist/whitelist.
So in a configuration where the images are blacklisted, if they are attached by superadmin, they are always displayed inline when using DownloadAction without even checking the blacklist. Now if we change this behaviour by not checking anymore if the user has PR, but by only relying on the blacklist, then those images would be always forced to be downloaded, that is the potentially breaking change I was talking about.