Centralize all mutations at the model level

This commit uses a new package that I need to document. It tries to
solve the long-standing debate in the Meteor community about
allow/deny rules versus methods (RPC).

This approach gives us both the centralized security rules of
allow/deny and the white-list of allowed mutations similarly to Meteor
methods. The idea to have static mutation descriptions is also
inspired by Facebook's Relay/GraphQL.

This will allow the development of a REST API using the high-level
methods instead of the MongoDB queries to do the mapping between the
HTTP requests and our collections.

1 files changed, 79 insertions, 0 deletions

diff --git a/models/attachments.js b/models/attachments.js
new file mode 100644
index 00000000..8ef0fef0
--- /dev/null
+++ b/models/attachments.js
@@ -0,0 +1,79 @@
+Attachments = new FS.Collection('attachments', {
+  stores: [
+
+    // XXX Add a new store for cover thumbnails so we don't load big images in
+    // the general board view
+    new FS.Store.GridFS('attachments'),
+  ],
+});
+
+if (Meteor.isServer) {
+  Attachments.allow({
+    insert(userId, doc) {
+      return allowIsBoardMember(userId, Boards.findOne(doc.boardId));
+    },
+    update(userId, doc) {
+      return allowIsBoardMember(userId, Boards.findOne(doc.boardId));
+    },
+    remove(userId, doc) {
+      return allowIsBoardMember(userId, Boards.findOne(doc.boardId));
+    },
+    // We authorize the attachment download either:
+    // - if the board is public, everyone (even unconnected) can download it
+    // - if the board is private, only board members can download it
+    //
+    // XXX We have a bug with the `userId` verification:
+    //
+    //   https://github.com/CollectionFS/Meteor-CollectionFS/issues/449
+    //
+    download(userId, doc) {
+      const query = {
+        $or: [
+          { 'members.userId': userId },
+          { permission: 'public' },
+        ],
+      };
+      return Boolean(Boards.findOne(doc.boardId, query));
+    },
+
+    fetch: ['boardId'],
+  });
+}
+
+// XXX Enforce a schema for the Attachments CollectionFS
+
+Attachments.files.before.insert((userId, doc) => {
+  const file = new FS.File(doc);
+  doc.userId = userId;
+
+  // If the uploaded document is not an image we need to enforce browser
+  // download instead of execution. This is particularly important for HTML
+  // files that the browser will just execute if we don't serve them with the
+  // appropriate `application/octet-stream` MIME header which can lead to user
+  // data leaks. I imagine other formats (like PDF) can also be attack vectors.
+  // See https://github.com/libreboard/libreboard/issues/99
+  // XXX Should we use `beforeWrite` option of CollectionFS instead of
+  // collection-hooks?
+  if (!file.isImage()) {
+    file.original.type = 'application/octet-stream';
+  }
+});
+
+if (Meteor.isServer) {
+  Attachments.files.after.insert((userId, doc) => {
+    Activities.insert({
+      userId,
+      type: 'card',
+      activityType: 'addAttachment',
+      attachmentId: doc._id,
+      boardId: doc.boardId,
+      cardId: doc.cardId,
+    });
+  });
+
+  Attachments.files.after.remove((userId, doc) => {
+    Activities.remove({
+      attachmentId: doc._id,
+    });
+  });
+}