We have a fun edge case that is breaking when the ImageProcessor tries to handle image requests with query strings.
Is there any way of turning it off?
Fun edge case:
The guidelines for running Umbraco load balanced suggests that the /App_Data folder be a virtual folder pointing to a shared folder accessible by each machine in the pool. We have found that without this being followed things can get very nasty.
None of the images on our site are ever referenced with query strings within our code and we are not actively using the image cropper for images managed by Umbraco.
However log files show that a small number of attempts have been made to retrieve images with long guid like query strings. We believe that these maybe caused by users with browser extensions that are affecting legitimate queries.
When this request is made the error logged is.
URL: www.{DOMAIN}.com/content/_Shared/Assets/images/btn-icons.png?bcsi-ac-{GUID}={GUID}=
USER AGENT: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)
Virtual path outside of the current application is not supported.
Parameter name: virtualPath
at System.Web.Security.UrlAuthorizationModule.CheckUrlAccessForPrincipal(String virtualPath, IPrincipal user, String verb)
at ImageProcessor.Web.HttpModules.ImageProcessingModule.<ProcessImageAsync>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar)
at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
at System.Web.Security.UrlAuthorizationModule.CheckUrlAccessForPrincipal(String virtualPath, IPrincipal user, String verb)
at ImageProcessor.Web.HttpModules.ImageProcessingModule.<ProcessImageAsync>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar)
at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
If we take the virtual folder /App_Data out of IIS then the request returns as expected.
But for our load balanced setup we can not do that we need to turn off ImageProcessor.
There appear to be a number of optional .config files not distributed with Umbraco to control ImageProcessor but even then there is no "OFF" switch.
Looking at the source code of ImageProcessor 2 it appears that there is no way of turning it off(with its own settings) and now way of excluding/including folders that allow processing.
You can take the module out of the web.config but please note that the cropper and the image resizing in the rich text editor rely on it, so you might get strange results.
I, too, need an off switch. The reason is I calculate a checksum on uploaded images, and ImageProcessing seems to optimize those images so that what's downloaded is in fact not identical with what was uploaded. Hence, the checksums don't match, and everything breaks down. I can confirm that removing ImageProcessing from web.config does make the problem go away.
How do I turn off the ImageProcessor?
We have a fun edge case that is breaking when the ImageProcessor tries to handle image requests with query strings.
Is there any way of turning it off?
Fun edge case:
The guidelines for running Umbraco load balanced suggests that the /App_Data folder be a virtual folder pointing to a shared folder accessible by each machine in the pool. We have found that without this being followed things can get very nasty.
None of the images on our site are ever referenced with query strings within our code and we are not actively using the image cropper for images managed by Umbraco.
However log files show that a small number of attempts have been made to retrieve images with long guid like query strings. We believe that these maybe caused by users with browser extensions that are affecting legitimate queries.
When this request is made the error logged is.
If we take the virtual folder /App_Data out of IIS then the request returns as expected.
But for our load balanced setup we can not do that we need to turn off ImageProcessor.
There appear to be a number of optional .config files not distributed with Umbraco to control ImageProcessor but even then there is no "OFF" switch.
Looking at the source code of ImageProcessor 2 it appears that there is no way of turning it off(with its own settings) and now way of excluding/including folders that allow processing.
So is there anyway to turn it off in Umbraco?
Or override its handling functionality?
You can take the module out of the web.config but please note that the cropper and the image resizing in the rich text editor rely on it, so you might get strange results.
It looks like James found a solution to this problem, so I expect an updated version soon that doesn't have this issue: https://github.com/JimBobSquarePants/ImageProcessor/issues/65
Thanks, I will wait for a fix.
There's still no off switch, I don't think I'll ever build one to be honest as I'd rather have bugs identified and fixed.
I've just this second released a fix for the issue though so enjoy :)
https://www.nuget.org/packages/ImageProcessor.Web
I, too, need an off switch. The reason is I calculate a checksum on uploaded images, and ImageProcessing seems to optimize those images so that what's downloaded is in fact not identical with what was uploaded. Hence, the checksums don't match, and everything breaks down. I can confirm that removing ImageProcessing from web.config does make the problem go away.
is working on a reply...