Add support for cropped image streaming
Problem -Increasing the value of MaximumReceiveMessageSize may increase the risk of [Denial of Service (DoS) attacks].
Description of what the problem: -Increasing the value of MaximumReceiveMessageSize may increase the risk of [Denial of Service (DoS) attacks] as microsoft say Microsoft Link.
Describe the solution you'd like -to solve this problem is by add method that will crop the image and return the image data as MemoryStream using IJSStreamReference so you don't need to increase the MaximumReceiveMessageSize size.
Pull Request
- Add method GetCroppedCanvasDataAsync that will return MemoryStream.
@Ali1Jamal sure we will have the similar endpoint in the future (next) version, based on that PR: https://github.com/CropperBlazor/Cropper.Blazor/pull/402
Thanks, @MaxymGorn — looking forward to it in the next release!
@Ali1Jamal cropping images in background with support chunking streams via maximumReceiveChunkSize variable is released now for 1.4.1 Cropper.Blazor version, e.g cropping: https://cropperblazor.github.io/examples/cropping#crop-in-background.
@MaxymGorn Thanks a lot for adding streaming support — much appreciated!
@Ali1Jamal thats done via not stream support because that also requires increasing size of message in SignalIr too or have problems in .net 6, my approaches based on interception JS stream blob for each pack chunks bytes[] to .net which more efficient and faster way to get image in blazor code and allow receive cropped images above 100mb, but somewhat difficult to implement
@MaxymGorn From what I understand, Blazor supports byte-array interop via Uint8Array without needing Base64. So why is the message size increasing as you said ? see this link byte-array-interop.
@Ali1Jamal when you are using Blazor Server with SignalIr and serializing bytes array as parameter in DotNetImageReceiver.invokeMethodAsync, these bytes message size will be increased during serialization inside SignalIr library dependent on byte number, brackets, commas and so on. You can all code of js interop in that place: https://github.com/CropperBlazor/Cropper.Blazor/pull/402/files#diff-7fef07d709a4ce1c9ba423f7c24406c9902d95a85593bae8d961d4c4a3a7a72dR387
i use the new version and i leave the default value for MaximumReceiveMessageSize in SignalR which's 32kb and i use Cropper.Blazor with maximumReceiveChunkSize as 30kb and try some images with some megabytes and every thing works good and i don't need to increase the MaximumReceiveMessageSize which's a good thing, well done ❤️
@Ali1Jamal perfect! This algorithm works with excellent byte accuracy, but you can do less just in case. 32kb is perfect message size because average size of byte is 2 which on average equal 32 768÷2 ≈16 384 array length of bytes due to blob was readed by default with 65,536 elements (~128kb) in that row: https://github.com/CropperBlazor/Cropper.Blazor/pull/402/files#diff-7fef07d709a4ce1c9ba423f7c24406c9902d95a85593bae8d961d4c4a3a7a72dR314 in your case each chunk stream will be sended via 2 portion, sometimes 3 portion if you have too large predicted message size. I will include more advanced parameter to control blob length when reading from the js stream controller, but that case only needed to accelerate processing very huge images, like over 30mb+ if process devices do it. Now it works perfectly for common cases from my perspective.
@Ali1Jamal after that fix we can pass more than 65 536 (~128kb when serialized via SignalIR) via one portion chunks via custom readable stream without additional crushing chunks after reading stream - https://github.com/CropperBlazor/Cropper.Blazor/pull/412/files#diff-7fef07d709a4ce1c9ba423f7c24406c9902d95a85593bae8d961d4c4a3a7a72dR330. I figure out for .net 6 we blazor js interop have limit ~ 133 000 bytes (~270kb when serialized via SignalIR), for other versions of dotnet (above 6) this limit is about ~3 times higher, this is due to the limits of blazor js interop via experimental method.
Overall, this will reduce the number of iterations with incomplete data and speed up the transfer, in addition, it gives more opportunities to control the size of the stream