3 ms·
I like the multipart aspect but the key signing and putting your keys in plaintext seems unnecessary. Here is an alternative: make a bucket with a policy where
by danielrhodes 12y ago
I like the multipart aspect but the key signing and putting your keys in plaintext seems unnecessary.
Here is an alternative: make a bucket with a policy where it will accept anonymous uploads (but not reads) and automatic object deletion after say 24 hours. You can then on the backend just copy the object to it's final destination. The simplicity means it becomes very versatile.
There is of course a risk that somebody will maliciously dump a huge file on you or many but it won't cost you anything because the files get automatically deleted. Furthermore, none of the files are publicly readable.
- mje__ 12y agoIt will cost you if you have a malicious uploader. I'm pretty sure S3 is not free just because you had objects in there for less than 24h. S3 supports pre-signed urls for exactly this use-case. EDIT: Nope, my bad. Doesn't look like S3 supports pre-signed urls for multipart uploads
- peedy 12y agoAs making a policy involves no communication with Amazon, I used to just create a policy on the fly for every upload request that said "allow upload to this specific key(path)". The key would be unique to every upload request. Once the upload is done, I'd just start processing the upload and move it where it belongs. Thus, in plaintext you'd have to put only your AccessID and a policy which would expire after a few minutes. EDIT: typo
- doctorpangloss 12y agoYou almost have it. Each user would receive a STS federated token, and their attached policy would give them permission to S3 keys prefixed with their user ID.