Is there any way to stop a user from uploading an image that are larger then say 5000px by say 2500px, as I have a site on cloud and they are using all there bandwidth by having images that are 6150 x 4100 that are 40MB in size event when we add crops to bring them down in size we are still seeing files about 10MB and this is taking all there bandwidth.
I want a way to stop an image been uploaded that is two large or some way of resampling the image on the site, with out having to download it, resize it in Gimp and then reupload it.
I found a package on the Umbraco Store yesterday that allows Image resizing in the back office but it seems to be broken.
It is also a good idea to set the HMACSecretKey to something (you decide what, it’s just a key). That way, no one can request arbitrary sizes from your frontend, thereby preventing further bandwidth-related attacks.
Don’t those settings only limit the maxWidth/Height you can have imagesharp resize too.. eg I could still upload a 40Mb image and it’s sat taking storage..
Specifies the maximum width and height an image can be resized to. If the requested width and height are both above the configured maximums, no resizing will be performed.
So is this only when we use getCropUrl, or a constructed url, if we specified over these sizes, but using Media.Url() would still serve a 40mb image?
Also that doc snippet seem to suggest oversize would return the native uploaded.. and if that’s 40Mb then that is what we get?
The HMACSecretKey does that also only work with getCropUrl and then preclude you from generating urls for when you want something bespoke that doesn’t really need a crop setting?
I think what you are looking for could be this setting:
Regarding the crops, are you aware that Image Processor can be requested to return images of a certain quality?(with the get paramter of quality ).
You could investigate setting that to lower the file size of the crops/processed images?
Yep I’d already mentioned those brute force iis settings that would result in thread closure, so large images not able to be uploaded…
But I think the original poster is after what used to be in v4/6 (or am I misremembering that) was it that on upload you could set a resolution/size that the native original image could not exceed and if it did then it was downsized before being persisted to the storage.
But yep also the quality can be used for bandwidth considerations, good shout.
You are absolutely correct. I was too quick; I thought it was about limiting outbound image requests. As far as I know, there is only the possibility to limit max image size for images inserted directly into the rich text editor.
You would have to write middleware that can intercept image uploads and verify their size, but that is a daunting task. Essentially, it would have to accept the upload, store it as a temporary file, use ImageSharp to resize the image, and lastly pass on the now-resized image to the request pipeline.
The getCropUrl method generates an HMAC and appends it to the URL automatically. If you want to do something bespoke, you have to generate the record of imagesharp options, then calculate an HMAC based on those.
You can call on IImageUrlGenerator.GetImageUrl(ImageUrlGenerationOptions? options) to calculate the final URI, but essentially the actual HMAC generation is a few lines:
if (_options.HMACSecretKey.Length != 0 && _requestAuthorizationUtilities is not null)
{
var uri = QueryHelpers.AddQueryString(options.ImageUrl, queryString);
var token = _requestAuthorizationUtilities.ComputeHMAC(uri, CommandHandling.Sanitize);
if (string.IsNullOrEmpty(token) is false)
{
queryString.Add(RequestAuthorizationUtilities.TokenCommand, token);
}
}
I had a thought that could be mitigated by hijacking the existing middleware for IFileStreamSecurityAnalyzer, with only a resize the image and continue the request pipeline to be added?
Yes, something like that could do it. This should be solved in ASP.NET land before it even hits Umbraco for sure. Note that you may hit a license limit with ImageSharp V3 when interacting with it directly, so either ensure you are GPL-compatible or use ImageSharp V2 instead.
That being said, it would not hurt for Umbraco to implement some sort of understanding of downsizing images specifically. But then what about videos? What about audio files? Those can be large, too, and there is no built-in Umbraco tool to handle them.
Wouldn’t video/audio ordinarily be streamed from a suitable third party and embedded?
(And the transcoding for responsivity that they provide)
Though obviously that doesn’t preclude storage of video/audio locally too..
With the ImageSharp v3/v2.. guess that’s the juggling act with anything to do with imageSharp these days… beyond getCropUrl/built url/ImageUrlGenerationOptions?
(Can we replace ImageSharp with SkiaSharp/netVips/Magic.Net as yet?)
I wonder if we can get at the TemporaryFileUploadValueBase : Src and use the internal ImageSharp Implementation so no license concerns, during the IFileStreamSecurityAnalyzer processing?
I’m not sure in which ways the license supports Umbraco exposing ImageSharp methods, as V3 must remain transitive to be supported.
I think the best bet is actually to make the Backoffice warn the user if they try to upload a large image, as you can get FileInfo based on modern web APIs for images.
As an editor uploading from a modern day smartphone… they still just go the path of least resistance which is upload the huge image?
But maybe a warn, with a backoffice extension to resize and save, (presumably that could be a getcropurl, and even if just httpclient to fetch the crop and resave… (if we can’t get direct fileaccess to the generated crop)??
If the warning (assignable) could include there may be added cost due to increased storage.. that might prompt a response
