I didn’t add anything new, merely looked at the outstanding PR’s and merged them in, and did some basic tests to make sure it still works. All the PR’s were pretty straight forward, no major changes.
Thanks for the info, sounds good! I just saw that one of these PRs ensures compatibility with Meteor 2.3 and up. Wasn’t aware about this breaking change in the package API.
One additional question: Is there a special reason why issues have been disabled on your branch? Since it is officially recommended by the Community Packages, I think issues should be collected there.
I wasn’t aware that issues were disabled by default. I turned them on now.
I used Meteor-Files just some days ago and I could see it is a very good package. In its very own description it says one of the features of the package is, precisely, that is well maintained.
I did not used their upload feature. I just needed to build downloadable links for some files that were in the server. So, there is a way to save the files that are already in the server and then, you can generate the links, from client or server, to download the files.
So, yes, I feel I can recommend this package. It seems it works very well. It’s well documented and one think I could sense was that it tries to be a simple to use package.
Hope this helps …
Thanks for the post @smrsoftware - my particular use-case is for end users to upload photos. So bypassing my meteor server makes a huge amount of sense where possible. I am still on the fence about whether I need to worry about signed URLs or not…
On one hand if someone has the URL, they could save the content and share just as easily as sharing the content itself. The URLs are not incremental in anyway so it isn’t as if someone could just attempt to load every single file in the bucket (well I mean they could try - not sure if S3 would rate limit/block that person). Even if they did that they might find an image but no metadata connecting it to a user/account.
On the other hand, more secure is always better right!
There is signed URLs for putting and getting, you can choose where to use it. For uploads it is a very nice way to go, just generate a (temporary) signed URL and let the user upload straight to it. For getting files I wouldn’t bother for your use case. I don’t know how long your URLs are but if you want to make it even more secure you can put them in a folder named after the userId. Guessing a URL then becomes virtually impossible.
get object URLs I would use for things like sensitive PDF documents and such.
I was wondering, how can i change the default storage-service URL ?
|Actually, I was wondering, how can I use the slingshot with Minio, in which Minio is compatible with the S3 API ?|
|Actually, I was wondering, how can I use the slingshot with Minio, in which Minio is compatible with the S3 API ? thank you
I have no idea what you are refering to.