summaryrefslogtreecommitdiffstats
path: root/models/attachments.js
diff options
context:
space:
mode:
authorMaxime Quandalle <maxime@quandalle.com>2015-09-08 20:19:42 +0200
committerMaxime Quandalle <maxime@quandalle.com>2015-09-08 20:19:42 +0200
commit45b662a1ddb46a0f17fab7b2383c82aa1e1620ef (patch)
treecc7be215c7e7ebffd2597df70cf271b3dd435e1a /models/attachments.js
parentc04341f1ea5efe082bf7318cf9eb0e99b9b8374a (diff)
downloadwekan-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 'models/attachments.js')
-rw-r--r--models/attachments.js79
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,
+ });
+ });
+}