We're seeing a constant stream of exceptions in the Umbraco Log of one of our sites, which seem to be derived from a Newsletter Studio component, and I'm curious about the cause and whether we can do anything to prevent these errors?
This is the logged stack trace:
System.IO.InvalidDataException: Found invalid data while decoding.
at System.IO.Compression.InflaterZlib.Inflate(FlushCode flushCode)
at System.IO.Compression.InflaterZlib.ReadInflateOutput(Byte[] outputBuffer, Int32 offset, Int32 length, FlushCode flushCode, Int32& bytesRead)
at System.IO.Compression.InflaterZlib.Inflate(Byte[] bytes, Int32 offset, Int32 length)
at System.IO.Compression.DeflateStream.Read(Byte[] array, Int32 offset, Int32 count)
at System.IO.Stream.InternalCopyTo(Stream destination, Int32 bufferSize)
at NewsletterStudio.Core.Utilities.Base62Converter.Decompress(Byte[] data)
at NewsletterStudio.Core.Utilities.Base62Converter.Decode(Byte[] value)
at NewsletterStudio.Web.Controllers.NewsletterStudioTrackingController.Image(String id)
at lambda_method(Closure , ControllerBase , Object[] )
at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c.<BeginInvokeSynchronousActionMethod>b__9_0(IAsyncResult asyncResult, ActionInvocation innerInvokeState)
at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`2.CallEndDelegate(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethod(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<>c__DisplayClass11_0.<InvokeActionMethodFilterAsynchronouslyRecursive>b__0()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<>c__DisplayClass11_2.<InvokeActionMethodFilterAsynchronouslyRecursive>b__2()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<>c__DisplayClass11_2.<InvokeActionMethodFilterAsynchronouslyRecursive>b__2()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethodWithFilters(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass3_6.<BeginInvokeAction>b__4()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass3_1.<BeginInvokeAction>b__1(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeAction(IAsyncResult asyncResult)
at System.Web.Mvc.Controller.<>c.<BeginExecuteCore>b__152_1(IAsyncResult asyncResult, ExecuteCoreState innerState)
at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncVoid`1.CallEndDelegate(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.End(IAsyncResult asyncResult, Object tag)
at System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncVoid`1.CallEndDelegate(IAsyncResult asyncResult)
at System.Web.Mvc.Controller.EndExecute(IAsyncResult asyncResult)
at System.Web.Mvc.MvcHandler.<>c.<BeginProcessRequest>b__20_1(IAsyncResult asyncResult, ProcessRequestState innerState)
at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncVoid`1.CallEndDelegate(IAsyncResult asyncResult)
at System.Web.Mvc.MvcHandler.EndProcessRequest(IAsyncResult asyncResult)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
The error does not appear to be impeding the sending or receiving of emails, but we would like to see it gone from our logs regardless.
These errors happen when an invalid tracking link is used, the code parsing the link fails to read the information and logs this error.
There could be a lot of underlying reasons to why this is happening, could be someone tampering with the URLs to "see what happens", it could also be some software that changes the content of the URLs eg. changing casing or something simular.
We get around 20-30 of these errors per day, which roughly corresponds to the number of emails being sent under normal circumstances.
None of these emails have tracking enabled, however, and most are simple notifications without links or images that could justify some sort of click tracking.
Also, I checked our webserver logs and I cannot see any incoming requests, failed or otherwise, corresponding to the timestamps in Umbraco's log. Is it possible that these errors are triggered by something internal to the site?
Looking at the stack trace of the error it looks like it's related to the "open tracking image".
See:
at NewsletterStudio.Web.Controllers.NewsletterStudioTrackingController.Image(String id)
It might be so simple that some mail-clients strips the tracking information from the image URL for privacy reasons so that the code that is parsing it fails. I have not seen this error before so it's kind of interesting. Are you saying that you can't see any errors in your other logs?
I will make sure to have a closer look at this and try to handle/log this error in a better way so that we can investigate further.
Please, allow a couple of days for me to implement something and then I'll get back here to let you know how to upgrade. Does that sound like a plan?
Ok, so I found the the corresponding entries in the web server log. I wasn't aware that IIS only logs in UTC, regardless of the servers time zone settings, so I was looking in the wrong place.
Umbraco logged another 4 of these errors last night, and this is what our web server saw:
I've started to think about if we could make our links all lower case but this is not yet been decided as this would make the links longer. I still need to think about this. As long as you make sure that the 301 to make links lower case is removed you should be fine.
Would adding /__ns/t/image/ to the Umbraco.Core.ReservedPaths option in web.config, as described in that thread, work for Newsletter Studio too? Are there other NSL endpoints that need to be kept from the grasp of the evil SEO checker as well?
It seems the SEO checker package leaves querystrings alone, so would it be possible to use this to evade the issue? If the request could be changed from
It would be a possible workaround but also a breaking change. I need to consider the impact of such a change. I'm not sure about the inner workings of SEO Checker but I'm quite sure that Richard (the creator) knows a way to create exceptions for certain URLs. Short term this is the way to go as any changes of this magnitude will take time for us.
NLS-derived exceptions in Umbraco Log
Hi!
We're seeing a constant stream of exceptions in the Umbraco Log of one of our sites, which seem to be derived from a Newsletter Studio component, and I'm curious about the cause and whether we can do anything to prevent these errors?
This is the logged stack trace:
The error does not appear to be impeding the sending or receiving of emails, but we would like to see it gone from our logs regardless.
Hi!
How often do you see this and how much?
These errors happen when an invalid tracking link is used, the code parsing the link fails to read the information and logs this error.
There could be a lot of underlying reasons to why this is happening, could be someone tampering with the URLs to "see what happens", it could also be some software that changes the content of the URLs eg. changing casing or something simular.
Hi,
We get around 20-30 of these errors per day, which roughly corresponds to the number of emails being sent under normal circumstances.
None of these emails have tracking enabled, however, and most are simple notifications without links or images that could justify some sort of click tracking.
Also, I checked our webserver logs and I cannot see any incoming requests, failed or otherwise, corresponding to the timestamps in Umbraco's log. Is it possible that these errors are triggered by something internal to the site?
Hi!
Looking at the stack trace of the error it looks like it's related to the "open tracking image".
See:
It might be so simple that some mail-clients strips the tracking information from the image URL for privacy reasons so that the code that is parsing it fails. I have not seen this error before so it's kind of interesting. Are you saying that you can't see any errors in your other logs?
I will make sure to have a closer look at this and try to handle/log this error in a better way so that we can investigate further.
Please, allow a couple of days for me to implement something and then I'll get back here to let you know how to upgrade. Does that sound like a plan?
// m
Ok, so I found the the corresponding entries in the web server log. I wasn't aware that IIS only logs in UTC, regardless of the servers time zone settings, so I was looking in the wrong place. Umbraco logged another 4 of these errors last night, and this is what our web server saw:
Looks to me like there's a redirect happening, which changes the casing of the requests.
Hi!
Great that you found this!
Yes, the redirect that changes the case of the characters is the problem as this will destroy the information in the token.
Do you know why this is happening? Any way you could create some exception for the /__ns/-route?
Hi again!
I've created an updated version of the package where we log these errors (when the token can't be parsed) as a debug-error.
Of course you'll have to see if you can remote the redirects that makes our links lower case but upgrading will also not fludder your log with errors.
Som more fixes included in the release as well: https://www.newsletterstudio.org/versions/3/
I've started to think about if we could make our links all lower case but this is not yet been decided as this would make the links longer. I still need to think about this. As long as you make sure that the 301 to make links lower case is removed you should be fine.
All the best!
Hi!
We found the culprit that caused the redirects: https://our.umbraco.com/packages/website-utilities/seo-checker/
Apparently, this package intercepts all requests to the site with uppercase characters in the url and forces them into lowercase with a redirect.
The uppercase redirect feature isn't visible or configurable in the UI in umbraco backend, but only briefly mentioned in the docs. This thread shows another case where that feature caused issues for another package: https://our.umbraco.com/packages/website-utilities/seo-checker/configuration/101278-is-there-a-way-to-restrict-paths-url-rewrite-is-applied-to
Would adding /__ns/t/image/ to the Umbraco.Core.ReservedPaths option in web.config, as described in that thread, work for Newsletter Studio too? Are there other NSL endpoints that need to be kept from the grasp of the evil SEO checker as well?
Another thought...
It seems the SEO checker package leaves querystrings alone, so would it be possible to use this to evade the issue? If the request could be changed from
to
...we could avoid the redirect while preserving the data string that I assume is what NLS needs to do its thing?
Hi!
It would be a possible workaround but also a breaking change. I need to consider the impact of such a change. I'm not sure about the inner workings of SEO Checker but I'm quite sure that Richard (the creator) knows a way to create exceptions for certain URLs. Short term this is the way to go as any changes of this magnitude will take time for us.
Cheers!
Hi
Just checking in to note that adding the following key to the appsettings section of web.config does appear to fix the issue:
Hi!
Great news! Thanks for sharing you solution and confirming that this works.
is working on a reply...