Are you executing this file after on your server, or just storing it?
Are you executing this file after on your server, or just storing it?
BBecause in that case files can contain malware anyways, even if they're a pdf or video
BEven if they might be the type you expect
Yyeah serverside is the best solution for max security, but bandwidth might be an issue
md5 is done on the client, so can be tampered as you mentioned
md5 is done on the client, so can be tampered as you mentioned
Yjust storing files, i'm not really worried about malwares
i just don't want users to store huge files and abuse my endpoint haha
1st time learning about file storage, just want to make sure I'm doing the best practices
i just don't want users to store huge files and abuse my endpoint haha
1st time learning about file storage, just want to make sure I'm doing the best practices
Ythank you all for you help, I appreciate it
B@yuvraj In that case the md5 + size validation should be good enough. If a user spoofs the type then that'll affect them if you serve it back to them for viewing/download on a client-side, but at that point it would be their fault and not your responsibility, as long as it doesn't breach the security of your server/other users then it's not really an issue you need to worry about.
BAnd yeah presigned urls in that case are likely still your best bet since processing the files on the server itself can be heavy on memory/server storage, even if you stream
BPeople who want their stuff to scale well should
BIt's not just scale either, it's probably faster to upload with a PutObject url as you don't need to send the file to the server and THEN the bucket, instead sending the file straight to the bucket
BSometimes it's better to sacrifice reliability. Don't cater to spoofers if they only affect themselves lol
B@Space Wdym? If its not gonna affect storage space or security or anything else that matters then don't worry about it. If a user spoofs then they should know what they're getting themselves into. Like you wouldn't add extra code to the client side just in case someone uses inspect element would you?
BAs you should
BBut if someone makes a dumb suggestion and gets a dumb response then what did they expect. As long as it doesn't affect anyone else
BWhat checks?
BI disagree
BThat's what generating the url on the server with the correct headers are for
BThe server? Since when is a user gonna access the server. If that's the case then you have bigger issues than just making sure the file is correct
BThe url generation doesn't touch the client-side
BThe needed metadata is sent to the server, the server itself validates the metadata e.g. size and then sets it as a necessary header on the url, send the url back, and then the client-side uses the url to put the file. If the client lies when using the url (e.g. mismatching what they sent to the server in terms of metadata like size) then the endpoint that's connected to the presigned url will reject it. This rejection isn't based on a client sending the header, instead it uses the file itself that got uploaded to the put url.
DAny file upload mechanism is “client authoritative” because the file being uploaded is from the client.
DYou can still validate the uploaded file after the fact and delete it if it’s not what’s expected (same as if you weren’t using R2).
DWell there’s only so much you can do to pre-validate something being uploaded by a client. You can enforce certain rules but the client can always “lie”… so things should still be validated after upload. This is not an R2 issue though. That’s the same for anything/any mechanism you use for user uploads.
BBalancing resource usage and reliability is important. If all companies think that way, with a who-knows-how-many validations for attributes that, if they were wrong, wouldn't even affect anyone other than the user, then those companies might not scale super well
B@Space
BBecause its a pretty important thing?
BFor a service that wants to expand
BAnd like I said before, it's not just scale, UX is affected that way because processing files on the server affects speed
DUser generated content should be validated regardless of the scale or storage system. If a user is supposed to upload an image, make sure it’s actually an image when you receive it for example. Same if you are just uploading direct to a single origin server (not using R2). A need to trust users for anything is already fail model for anything.
B@digitalpoint validating everything can still take a lot of resources, you sacrifice reliability slightly with the presigned urls but if a user can't spoof anything that affect the server negatively nor other users (aka only affecting themselves) then it's not really an issue to waste time on. A user that tampers with things like that should not expect a good experience on the client-side. Of course if you can validate unimportant attributes without significant resource usage then go ahead, but something like content type isn't as easy to validate. And even if you do, how do you know that's correct? Does your algorithm scan the entire file for the type, or just the magic numbers at the start? Well what if the user spoofs that too?
CI think it's way more complex then that. A lot of companies use S3 presigned for uploads on websites, it really depends on your scope (is this just a generic upload website), or is this an internal company thing so if an admin uploads an img it's whatever, or is this an image all users would see?
BExactly
BDepends on who it affects
CImages are small enough that you may want to just proxy them through your backend and check, for larger things makes way less sense for it all go through your backend
DI guess it just depends on the content and the site can make that decision. For me, I don’t even trust admins to do things right. Like images they upload have EXIF data stripped and converted to WEBP when it’s uploaded.
DAnd as part of that process, it’s easy enough to check if the input is a valid image since it’s being mucked with anyway.
DSame with user uploaded .zip files… if the files are supposed to be in a specific hierarchy in the archive, check that. Obviously you can’t check everything, but a lot you can.
Cyea, sometimes can do it client side too. I have something where users pick images, the client-side code checks image, and then they can pick to upload directly to bucket. It's b2b software so I really doubt someone would try to jump the check but even if they do it's on them, only they can see their own messed up imgs lol, just want to have sane max upload limits so they can't say "this 1gb file is totally an image"
BAnd presigned urls make size validation easy
Cwell you clamp that down to reasonable limits lol
Cclient says it wants to upload image, requested size 500 mb but images can be up to 25 mb, not going to return a presigned url
Cthen you have rate limits on the presign endpoint + a short expiration on the presigned sig
Cwhatever makes sense for your app? This isn't something that proxying it through your backend would magically solve
Cok..?
BAnd that's a good thing
BDon't need to set a large expiry in case a user wants to upload a large file.
Cno because you'd have to start a new upload
Cyou can take as long as you want to upload sure, and that's fine because you're consuming r2's resources/keeping a conn open to them
Cbut once that upload is done/failed/suceeded, you try again, new sig expiration check
Cidk if r2/s3 stuff would let you do that
Cwould have to look into it, I assume there should be some same max concurrent limit