3 ms·

Hi Jerome. Thanks for the kind words. In regards to your concern, the way we imagine this playing out is that in your app, the client asks to upload something.

Hi Jerome. Thanks for the kind words. In regards to your concern, the way we imagine this playing out is that in your app, the client asks to upload something. You use an ajax request to ask your server, with your cookies, if this is allowed. If the user is allowed, you can create a policy and sign it. You should also set the min and max size on the policy. Then you can pass this along. Thus, you know of and approve of every upload request. Does that sound reasonable? We has also considered a post upload hook where you approve of it. However, we imagined that people would not only want to know the metadata, but maybe even the contents before approving it which seems silly to pass the entire data around. I think what will really help is if you set up the policy as outlined above, and then, do the clean up that you mentioned when we do webhooks where you could sign up to receive a notification after every upload.

jeromeparadis 14y ago
Yeah, we'll manage it exactly as you mention and do some cleanup. As for the idea of webhooks, in our case, we wouldn't need the content, just the meta data. That's what we already do anyway: we only store references to the S3 files we created. The idea is that it simplifies be able to run multiple Web server instances by having this user generated content offsite. My concern was really more about us confirming what we receive to you so you could do the cleanup of non acknowledged files instead of us doing it. What you are suggesting is an additional verification that can have value but doesn't address the question of constituency between what ends up in our S3 buckets and what we end up being aware off in our app. In any case, no big worry but I'll email you details.
jeromeparadis 14y ago
My bad, your webhook proposal, thinking of it, would indeed facilitate immensely the integrity between our database and the S3 files. It would require us coding a scheduler. But it would be easy to write and would be way more efficient (than what we can do today). Would simply need to check your notifications against our database and accordingly clean up/validate the files in the S3 buckets. Great stuff.

jeromeparadis 14y ago

Yeah, we'll manage it exactly as you mention and do some cleanup. As for the idea of webhooks, in our case, we wouldn't need the content, just the meta data. That's what we already do anyway: we only store references to the S3 files we created. The idea is that it simplifies be able to run multiple Web server instances by having this user generated content offsite. My concern was really more about us confirming what we receive to you so you could do the cleanup of non acknowledged files instead of us doing it. What you are suggesting is an additional verification that can have value but doesn't address the question of constituency between what ends up in our S3 buckets and what we end up being aware off in our app. In any case, no big worry but I'll email you details.

jeromeparadis 14y ago

My bad, your webhook proposal, thinking of it, would indeed facilitate immensely the integrity between our database and the S3 files. It would require us coding a scheduler. But it would be easy to write and would be way more efficient (than what we can do today). Would simply need to check your notifications against our database and accordingly clean up/validate the files in the S3 buckets. Great stuff.