@yuvraj In that case the md5 + size validation should be good enough. If a user spoofs the type then

@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.

Barry_Based_BensonOP•8/22/24, 4:08 PM

And 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

Barry_Based_BensonOP•8/22/24, 4:12 PM

People who want their stuff to scale well should

Barry_Based_BensonOP•8/22/24, 4:18 PM

It'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

Barry_Based_BensonOP•8/22/24, 4:19 PM

Sometimes it's better to sacrifice reliability. Don't cater to spoofers if they only affect themselves lol

Barry_Based_BensonOP•8/22/24, 4:21 PM

@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?

Barry_Based_BensonOP•8/22/24, 4:22 PM

As you should

Barry_Based_BensonOP•8/22/24, 4:23 PM

But 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

Original message was deleted

Barry_Based_BensonOP•8/22/24, 4:24 PM

What checks?

Barry_Based_BensonOP•8/22/24, 4:24 PM

I disagree

Barry_Based_BensonOP•8/22/24, 4:24 PM

That's what generating the url on the server with the correct headers are for

Barry_Based_BensonOP•8/22/24, 4:26 PM

The 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

Barry_Based_BensonOP•8/22/24, 4:27 PM

The url generation doesn't touch the client-side

Barry_Based_BensonOP•8/22/24, 4:30 PM

The 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.

digitalpoint•8/22/24, 4:32 PM

Any file upload mechanism is “client authoritative” because the file being uploaded is from the client.

digitalpoint•8/22/24, 4:33 PM

You 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).

digitalpoint•8/22/24, 4:35 PM

Well 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.

Barry_Based_BensonOP•8/22/24, 4:35 PM

Balancing 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

Barry_Based_BensonOP•8/22/24, 4:36 PM

@Space

Barry_Based_BensonOP•8/22/24, 4:36 PM

Because its a pretty important thing?

Barry_Based_BensonOP•8/22/24, 4:36 PM

For a service that wants to expand

Barry_Based_BensonOP•8/22/24, 4:37 PM

And like I said before, it's not just scale, UX is affected that way because processing files on the server affects speed

digitalpoint•8/22/24, 4:38 PM

User 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.

Barry_Based_BensonOP•8/22/24, 4:43 PM

@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?

Ddigitalpoint User generated content should be validated regardless of the scale or storage sy...

Chaika•8/22/24, 4:46 PM

I 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?

CChaika I think it's way more complex then that. A lot of companies use S3 presigned for...

Barry_Based_BensonOP•8/22/24, 4:46 PM

Exactly

Barry_Based_BensonOP•8/22/24, 4:46 PM

Depends on who it affects

Chaika•8/22/24, 4:47 PM

Images 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

digitalpoint•8/22/24, 4:48 PM

I 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.

digitalpoint•8/22/24, 4:48 PM

And 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.

digitalpoint•8/22/24, 4:50 PM

Same 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.

Ddigitalpoint Same with user uploaded .zip files… if the files are supposed to be in a specifi...

Chaika•8/22/24, 4:52 PM

yea, 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"

Barry_Based_BensonOP•8/22/24, 4:54 PM

And presigned urls make size validation easy

Chaika•8/22/24, 4:56 PM

well you clamp that down to reasonable limits lol

Chaika•8/22/24, 4:57 PM

client 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

Chaika•8/22/24, 4:59 PM

then you have rate limits on the presign endpoint + a short expiration on the presigned sig

Chaika•8/22/24, 4:59 PM

whatever makes sense for your app? This isn't something that proxying it through your backend would magically solve

Chaika•8/22/24, 5:00 PM

ok..?

Barry_Based_BensonOP•8/22/24, 5:00 PM

And that's a good thing

Barry_Based_BensonOP•8/22/24, 5:00 PM

Don't need to set a large expiry in case a user wants to upload a large file.

Original message was deleted

Chaika•8/22/24, 5:01 PM

no because you'd have to start a new upload

Chaika•8/22/24, 5:01 PM

you 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

Chaika•8/22/24, 5:01 PM

but once that upload is done/failed/suceeded, you try again, new sig expiration check

Chaika•8/22/24, 5:02 PM

idk if r2/s3 stuff would let you do that

Chaika•8/22/24, 5:02 PM

would have to look into it, I assume there should be some same max concurrent limit

Chaika•8/22/24, 5:03 PM

yea idk about that, would assume there's some protection there with how many people use it w/ s3 and such but would have to look into it further. At some point w/ Cf ddos prot would kick in

Chaika•8/22/24, 5:05 PM

everything behind cf cdn has automatic protection

Barry_Based_BensonOP•8/22/24, 5:07 PM

A few second flood of class A ops that CF can mitigate VS processing every single file on your backend.

Like I said you sacrifice some things and win others. It's a pros cons situation

Barry_Based_BensonOP•8/22/24, 5:07 PM

I'd rather go the presigned url route in this case

Chaika•8/22/24, 5:11 PM

You could sign If-None-Match/If-Unmodified-Since, not sure if that would save you the Class A though. Would have to test if you can do multiple presigned uploads at once

Original message was deleted

Chaika•8/22/24, 5:11 PM

do you know if it lets you actually do more then one at once?

@yuvraj In that case the md5 + size validation should be good enough. If a user spoofs the type then

Similar Threads