Sitecore Boost User functionality

The murder 

Recently, we were contacted by a customer who had been faced with an additional license cost by Sitecore due to excessive use of the Boost User functionality.

For those of you who have never encountered this behavior, the documentation for this functionality can be found here:

https://doc.sitecore.com/xp/en/developers/90/platform-administration-and-architecture/kick-off-or-add-a-user.html#increase-the-number-of-allowed-users

However, the customer asked us (as their partner agency) to check or challenge this boost behavior.

They wanted to know who and how often (in a more granular metric than a day) this boost had been used.

The investigation

At first I though this was going to be something quite simple. As Sitecore is apparently able to detect the boost actions as they were performed I assumed that they should be able to also track the IP, Username, date and any other related information.

But as it goes... never make assumptions :) Sitecore told us that they can only see the time and occurrences summarized into a single day. This is probably to GDPR, and whether or not they store more than this was impossible for me to tell, but the screenshot can be found below:

So we started to dig. A user can only see this information once they perform a valid login and are faced with the following screen:

This gave me good hopes that there would be something valuable in the Sitecore logs that could help me determine who had actually performed the boosts (and if this had even occurred at all). A possible assumption was that it was a temp, or external contractor, so the customer really wanted to know.

However, after skimming through the logs, no information on this was found at all.

At this point the only way forward seemed to be to log this as a Sitecore support ticket and see what they would be able to come up with...

The manhunt

I dubbed this the 'Manhunt' as we were going to have to get our hands dirty on this one.

Feedback had come from Sitecore and there was some coding (read: copying) to be done in order to handle future boost events and write them into our logs...

This was the solution Sitecore Support provided us with:

1. Create a custom BoostUsersControllerclass (the rest of the code can be found in the BoostUsersControllersource class in Sitecore.Client.LicenseOptions.dll):

using Sitecore.Diagnostics;
namespace Sitecore.Support.Client.LicenseOptions.Controllers
{
    public class BoostUsersController : Controller
    {
                 [HttpGet]
                 public void RedirectToBoost()
                 {
                         if (!Context.User.IsAuthenticated)
                         {
                                  base.Response.StatusCode = 401;
                         }
                         else
                         {
                                  string username = Context.GetUserName();
                                  Log.Info("Boost used by: " + username, this);
                                  base.Response.Redirect(GetBoostUrl(), endResponse: true);
                         }
                 }

                 protected string GetBoostUrl()
                 { ... }
        }
}

2. Create InitializeRedirectToBoostRouteclass

namespace Sitecore.Support.Mvc.Pipelines.Initialize
{
    internal class InitializeRedirectToBoostRoute
    {
        public virtual void Process(PipelineArgs args)
        {
            Assert.ArgumentNotNull(args, "args");
            this.RegisterRoutes(RouteTable.Routes, args);
        }

        protected virtual void RegisterRoutes(RouteCollection routes, PipelineArgs args)
        {
            string[] namespaces = new string[] { "Sitecore.Support.Client.LicenseOptions.Controllers" };
            routes.MapRoute("RouteName", "api/sitecore/BoostUsers/{action}", new
            {
                controller = "BoostUsers",
                action = "RedirectToBoost",
                id = UrlParameter.Optional
            }, namespaces);
        }
    }
}

3. Compile the above classes and copy the .dll file to the \bin folder.
4. Create a patch file for your custom processor in the <initialize>pipeline.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <pipelines>
          <initialize>
            <processor type="Sitecore.Support.Mvc.Pipelines.Initialize.InitializeRedirectToBoostRoute, AssemblyName" patch:before="processor[@type='Sitecore.Mvc.Pipelines.Initialize.InitializeCommandRoute, Sitecore.Speak.Client']"/>
          </initialize>
        </pipelines>
  </sitecore>
</configuration>

The kill / The capture

Even though the above solution will probably make our lives easier for future cases to come... the idea and initial premise was to find out why and if this 'Boost Users' feature had been used.

Which meant we needed a solution for whatever lay in the past.

This got us thinking one layer up...

Maybe something has simply been logged into the IIS logs...

And YES :p The default IIS logs do hold this information apparently:

Line 11538: 2022-12-20 13:37:28 10.75.9.150 GET /api/sitecore/BoostUsers/RedirectToBoost - 443 sitecore\USERNAME 111.222.3.444 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/108.0.0.0+Safari/537.36 https://cm-CUSTOMER.reference.be/sitecore/client/Applications/LicenseOptions/StartPage 352 0 0 249

Which, unmistakenly, told us that USERNAME (you know who you are!) was the culprit!

So, lesson learned:

1. Always check your logs
2. Immediately open up a Support ticket, they can really help
3. ALWAYS check ALL your logs
4. Read blogs like this.

Take the above solution if you need to add this into your configuration, but the basics are stored by default in your logs regardsless.