vsivsi / meteor-file-collection

Extends Meteor Collections to handle file data using MongoDB gridFS.
http://atmospherejs.com/vsivsi/file-collection
Other
159 stars 37 forks source link

On PUT, response string sends back default meteor template...would prefer JSON file object #81

Closed lspellman closed 8 years ago

lspellman commented 8 years ago

I perform a PUT and get back a 200 response code...which is good! However, for some reason I was expecting to get back a response as well...something like the JSON of the fs.files object we just put up there:

{ "_id" : ObjectId("95e5df6b34de1b0de15f5f1e"), "length" : 0, "md5" : "d41d8cd98f00b204e9800998ecf8427e", "uploadDate" : ISODate("2016-01-28T21:12:25.118Z"), "chunkSize" : 2096128, "filename" : "1C04-DELTA-Rev.1.pdf with tr 25-05.pdf", "metadata" : {

},
"aliases" : [ ],
"contentType" : "application/octet-stream"

}

I was planning on using the MD5 generated by the PUT to update some other records. So without this response, I have to use Restivus to make an API call to the same fs.files object to retrieve it.

vsivsi commented 8 years ago

Returning the file object (with/any all of its metadata, etc) would represent a potential security risk. The allow/deny system in file-collection (and the related publish/subscribe) separate out permission to write data to an existing file (what the PUT does) from permissions to create, read, delete and access its metadata. So returning file metadata from a successful PUT would violate that separation of access permissions.

You can either access such information via normal meteor pub/sub on the file-collection, by calling a custom DDP method, or by defining a custom HTTP API to GET such data.

lspellman commented 8 years ago

Makes sense, thanks!

vsivsi commented 8 years ago

Also, You can define your own custom express-style HTTP PUT .handler function when you define the route. If you base it off of the stock handler function, it wouldn't be very much work to implement exactly what you expected to see.