
In the wake of a recent
article about resizing images on a server, I decided to share the experience of implementing the
ImageResizer module for IIS. Of course, writing a simple review would be too boring, but we didn’t limit ourselves to a simple implementation of the module.
So, we had a purchased ImageResizer +
Cloud Bundle plugin for working with clouds.
Unfortunately, I am forbidden to name projects in which this solution is implemented, but I can outline the essence. These are news portals focused on North America. The site contains articles and video clips.
Articles are stored in the database, the editor can attach the title picture to the article. The image is stored in Amazon S3. As you understand, the editor can upload an image, both small and huge, and one should not lose the original.
Video files are uploaded, processed, and stored in the
BrightCove video cloud storage. After the video is uploaded to the storage, it is fully processed, recoded into several streams of different formats and a thumbnail is automatically selected for the video.
Naturally, since all this happens in the cloud, then the picture is stored in the cloud, and we get a direct link to insert. But even here the picture can not always correspond to the required size.
')
In total, we have a set of images in Amazon S3, a set of images in BrightCove, and all images need to be able to quickly give already fitted to the desired size. In addition, different image sizes can be used in different parts of the site. We did not have a set of
plug-ins for caching , but we had CloudFront.

Strangely enough, the comrade
bitmap did not mention in his article exactly how he changes the image size, because there are many ways (you can see the torment in finding out the necessary option with the customer in the photo). You can stretch into the frame, getting stretched faces, you can save proportions and fill the vacant space with color. You can keep the proportions and trim the edges. The module also allows a bunch of ryushechek we do not need, such as the blending of filters and other things. As a result, on one project we began to stretch in the same way as stretching css, and on another project we filled in color.
Standard script
By default, out of the box it is assumed that the images and IIS are located on the same server and resizing is performed by simply adding parameters to the link:
/image.jpg?height=200&width=300
or
/image.jpg?h=200&w=300
.
Great, but how to pick up images from Amazon S3?
S3 reader
This is where the first of the Cloud Bundle plug-ins comes into play:
S3 Reader . Using simple web.config settings, it allows you to use the link in the following format:
/s3/bucket/folder/image.jpg?h=200&w=300
RemoteReader plugin
Ok, now we can give pictures from S3, but S3 is quite a popular thing, how about a completely third-party server? This is where the
RemoteReader plugin is enabled . There is not so simple. The final link has the following format:
/remote.jpg.ashx?w=200&height=300&urlb64=45b45c4a2099b...&hmac=a2099ba2099b
.
Where remote.jpg.ashx is the end point for the module to intercept the link, the urlb64 parameter is a simple link to the remote server with a picture that is encrypted with HMAC SHA-256. This link generates a special method:
RemoteReaderPlugin.Current.CreateSignedUrl("http://remote.com/image.jpg");
Cloudfront
Ok, we coped with the main task. Now you need to somehow cache the result, otherwise it will not work quickly.
We have no caching plug-ins, but there is such a magical thing as CloudFront custom origin. We have created a new distribution of CloudFront, pointing to our domain. So now we have the format links:
htt://my-distribution-name.cloudfront.com/remote.jpg.ashx?w=200&height=300&urlb64=45b45c4a2099b...&hmac=a2099ba2099b
and
htt://my-distribution-name.cloudfront.com/s3/bucket/folder/image.jpg?h=200&w=300
But now our site began to open at https: //my-distribution-name.cloudfront.com, clogging the cloudfront. Then we quickly added a section for pictures. And CloudFront from the link
htt://my-distribution-name.cloudfront.com/s3/bucket/folder/image.jpg?h=200&w=300
I began to redirect the request to
htt://my-site.com/images/s3/bucket/folder/image.jpg?h=200&w=300
It seems that the whole should work, but suddenly it turned out that CloudFront mercilessly chops long lines of parameters and we received tons of errors and not opening pictures. Here the
CloudFront plugin helped us, which allowed us to convert links to the following format:
htt://my-distribution-name.cloudfront.com/remote.jpg.ashx;w=200;height=300;urlb64=45b45c4a2099b...;hmac=a2099ba2099b
and
htt://my-distribution-name.cloudfront.com/s3/bucket/folder/image.jpg;h=200;w=300
Short links
All this worked fine, but engineering thought went even further. What if someone starts generating unnecessary image resolutions? The maximum size of the increase is of course limited, but still it is possible to follow the DODOS site, and even the resulting pictures will be distributed across hundreds of CloudFront servers around the world. And of course the length of the link is just awful. Then we decided to implement the functionality of short links.
When generating a link, we add to the database the resulting long link of the form:
/remote.jpg.ashx;w=200;height=300;urlb64=45b45c4a2099b...;hmac=a2099ba2099b
and get its id in the table. In the layout we spit out a format link:
htt://my-distribution-name.cloudfront.com/42
CloudFront addresses us at:
htt://my-site.com/i/42
We intercept the request, select the long link by key 42 from the database, in the server code we do the HttpRequest to ourselves, so that it is intercepted by the ImageResizer and in response we give the result of its work. CloudFront adds the resulting image on its servers and we no longer receive this request until the next cache invalidation.
And the final touch is hiding the terrible prefix of the CloudFront link, which is a random collection of numbers and letters, which is also not very nice with the help of an additional domain.
As a result, the end user link is:
htt://short.com/42
At the same time, the image is cached, easily accessible from the server closest to the user, the malicious hacker cannot resize on his own, after DDOS is our module, we have a short link and most importantly all the pictures with the right dimensions look beautiful in their places.
Conclusion
In conclusion, I want to say that the plugin works fine, has a bunch of different settings and plug-ins for all occasions, it has a debug mode in case of unforeseen situations. The author is responsible for handling problems and even seems to pay for the bugs found. Of course, the module is paid, but worth it.