You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a use case with multipart form data uploads where the uploading file is bundled together with the auth in the same form.
Now that creates an issue in Dart Frog where we can't authenticate the signature/token before the entire form data is cached on the server.
This means that we can't reject the request before caching the entire file ergo, somebody can send a couple of 1GB requests and overload the server.
It would be great if we could have something like reading the fields by order, get the auth ones first, verify them and then accept the rest or reject the request.
One would think that it would be the best to put the auth in the header but for some reason AWS S3 has it in the form data fields with the file. I don't know if there are some security implications etc. But anyone that wants to make an S3 compatible endpoint this will be a deal breaker issue.
We talked about this on the bloc discord, an idea to look into is using sync generators and iterables to only parse as much as the user requests instead of everything in one go
Theoretically it is possible but we need to verify if this is feasible and user-friendly
Description
There is a use case with multipart form data uploads where the uploading file is bundled together with the auth in the same form.
Now that creates an issue in Dart Frog where we can't authenticate the signature/token before the entire form data is cached on the server.
This means that we can't reject the request before caching the entire file ergo, somebody can send a couple of 1GB requests and overload the server.
It would be great if we could have something like reading the fields by order, get the auth ones first, verify them and then accept the rest or reject the request.
One would think that it would be the best to put the auth in the header but for some reason AWS S3 has it in the form data fields with the file. I don't know if there are some security implications etc. But anyone that wants to make an S3 compatible endpoint this will be a deal breaker issue.
Further context
The text was updated successfully, but these errors were encountered: