Description

It is currently possible to restrict the size of attachments in a Space. It is interesting to be able to also restrict attachments according to their mimetype in a Space.

Requirements

• UC1: Users should be restricted to upload attachments according to their mimetype
• UC2: Admins should be able to configure the allow/block lists at any level
• UC3: Admins should be able to configure at least the root allow/block lists from an Administration UI

Limitations

• The control is no part of the attachments API, but is at the user level. Consequently, extensions are not impacted and are allowed to make define their own restrictions
• Mimetypes are inferred (either client side by the browser, of client side using third-party such as Tika) and can be tricked. This feature must be seen as a way to guide users to use some types of documents but is not a security feature

Other goal

• Currently, error messages for file size restriction are not uniform and can be very generic. The goal is to have localized and accurate message everywhere a file restriction applies.

Impacts

• REST API: AttachmentResource#putAttachment and AttachmentsResource#addAttachment
• attachment pane
• xar import in the admin
• other places in the admin?

Implementation

xwiki.properties

XClass

Attachment.Code.AttachmentMimetypeRestrictionClass

Two text fields:

• allowedMimetypes
• blockedMimetypes

Initialized using a mandatory document initializer in xwiki-platform-attachment-api.

Prevent non-admin users to update Attachment.Code.AttachmentMimetypeRestrictionClass XObject

Same as for rights, (see org.xwiki.security.authorization.internal.RightsFilterListener). A listener listen for document creation and update, and check whether the user performing the action is allowed to edit XWikiRights XObject (i.e., is an admin).

I propose to do the same for mime type restrictions XObjects.

Prevent Attachment.Code.AttachmentMimetypeRestrictionClass value inconsistencies

It could be possible for admins to be less restrictive on a given space than it parent (and it is easy to become Admins of a space without being globally admin).

• Option 1: no restrictions
• Option 2: always be more restrictive than the parent space
• Option 3: always be more restrictive than a given XObject (configurable?)
• Option 4: always be more restrictive than the xwiki.properties

Prevent inconsistencies on attachment move

Currently, no check is done on move, which means that you can upload a large file in a space, and move it in a space where it wouldn't be allowed.

Without further controls, the same will be true for mimetype restrictions.

• Option 1: no restrictions
• Option 2: add a control to check if the move attachment passes the restriction check on the target space and raise an error if it does not.

Note that option 2 might lead to a situation where an attachment cannot be moved or renamed anymore if the restrictions of its space are made stricter after upload.