Presigned URLs (S3 upload): file type verification, image transformation & cleanup/delete
When implementing S3 upload, a lot of examples I've found (and also Theo's recommendation afaik) are using presigned URLs.
Maybe I'm missing something, but I have three questions about this:
1. Verify file type
S3 allows to restrict the "content type", so e.g. only jpg or png. But it does not actually check the file itself, only the extension (as part of the file name). Users can upload .png files that are actually .txt files, just by renaming the file. You cannot check the MIME type without a server inbetween.
How do you verify the file type?
2. Image transformation
Don't you care about the image size? You can only reliably convert the size on the server, which obviously does not work with presigned URLs. I know you can restrict the image size via presigned URLs, but don't you want to decrease the file size (of e.g. a jpg) to save some costs of the storage?
3. Cleanup old images
When a users "replaces" an image (imagine an avatar), you need to delete the old image as well. This can only be done reliably on the server as well if you want to make sure that "upload" and "delete" is done in one operation (the API request).
I guess one could also model the storage path via a fixed ID, so you just overwrite the image in the storage, but it sometimes you need random file names, no?
In general: Is really everyone using presigned URLs?
If yes, how do you overcome the three mentioned topics?
Maybe I'm missing something, but I have three questions about this:
1. Verify file type
S3 allows to restrict the "content type", so e.g. only jpg or png. But it does not actually check the file itself, only the extension (as part of the file name). Users can upload .png files that are actually .txt files, just by renaming the file. You cannot check the MIME type without a server inbetween.
How do you verify the file type?
2. Image transformation
Don't you care about the image size? You can only reliably convert the size on the server, which obviously does not work with presigned URLs. I know you can restrict the image size via presigned URLs, but don't you want to decrease the file size (of e.g. a jpg) to save some costs of the storage?
3. Cleanup old images
When a users "replaces" an image (imagine an avatar), you need to delete the old image as well. This can only be done reliably on the server as well if you want to make sure that "upload" and "delete" is done in one operation (the API request).
I guess one could also model the storage path via a fixed ID, so you just overwrite the image in the storage, but it sometimes you need random file names, no?
In general: Is really everyone using presigned URLs?
If yes, how do you overcome the three mentioned topics?
