A critical vulnerability was discovered in React Server Components (Next.js). Our Systems Remain Fully Protected. Learn More.
AI OnAI Off
A critical vulnerability was discovered in React Server Components (Next.js). Our Systems Remain Fully Protected. Learn More.
Hello (Episerver) World!
I believe I have found a rather interesting little bug within the EPiServer.Marketing.KPI.2.4.1 package. I have searched through the release notes to see if a similar bug had been reported and fixed, but I did not find anything. I want to report what I found to see if there is a known solution for this issue and to raise awareness in case there is not a known solution. The site in question is currently running CMS 10.10.x.
To give some context, an editor recently started an A/B test on the Start Page with a "Time on Page" KPI and a "Site Stickiness" KPI. After this was set up, we started to see an increase in
NullReferenceExceptionbeing reported in Application Insights for a small set of global assets, including one in particular that was going to be included in a wide-ranging marketing email. Here is the stack trace for the error in question:After a bit of decompiling and debugging, I determined that the error seems to reliably occur when given the following:
EPiServer.Marketing.KPI.Common.StickySiteKpi.IsSupportingContentContentReference.StartPage) in order to render navigation, footer, and the like as part of a multi-site setup.Given the above conditions, the Start Page will be loaded from the content repository as part of rendering the Not Found page and
EPiServer.Marketing.KPI.Common.StickySiteKpi.AddSessionOnLoadedContentwill subsequently be called. Because the Start Page is the content under test, and because the current url contains "/globalassets", and because the SSK_ cookie is not included in the request,EPiServer.Marketing.KPI.Common.StickySiteKpi.IsSupportingContentwill return "true" and the KPI will unsuccessfully attempt to dereferenceHttpContext.Current.Request.UrlReferrer.AbsolutePath.Even though this bug mainly occurs when the url will cause a 404 response, if the server error response gets cached by the CDN for an asset that will eventually be published (which happened here), this can quickly become a large issue if the PDF/asset is highly important for some business reason. I don't have a question here per se but I am interested in any comments or critiques of my analysis as well as finding out if others have run into this problem :)
Thanks,
Christian