diff options
author | Maxime Quandalle <maxime@quandalle.com> | 2015-09-08 20:19:42 +0200 |
---|---|---|
committer | Maxime Quandalle <maxime@quandalle.com> | 2015-09-08 20:19:42 +0200 |
commit | 45b662a1ddb46a0f17fab7b2383c82aa1e1620ef (patch) | |
tree | cc7be215c7e7ebffd2597df70cf271b3dd435e1a /collections/attachments.js | |
parent | c04341f1ea5efe082bf7318cf9eb0e99b9b8374a (diff) | |
download | wekan-45b662a1ddb46a0f17fab7b2383c82aa1e1620ef.tar.gz wekan-45b662a1ddb46a0f17fab7b2383c82aa1e1620ef.tar.bz2 wekan-45b662a1ddb46a0f17fab7b2383c82aa1e1620ef.zip |
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.
Diffstat (limited to 'collections/attachments.js')
-rw-r--r-- | collections/attachments.js | 79 |
1 files changed, 0 insertions, 79 deletions
diff --git a/collections/attachments.js b/collections/attachments.js deleted file mode 100644 index 8ef0fef0..00000000 --- a/collections/attachments.js +++ /dev/null @@ -1,79 +0,0 @@ -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, - }); - }); -} |