Closed lspellman closed 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.
Makes sense, thanks!
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.
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" : {
}
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.