I’m writing this up so I have a convenient reference for future projects — it looks like there’s a bug with Sitecore’s Analytics library and how it handles IP addresses through an Azure Application Gateway.
Sitecore relies on the X-Forwarded-For HTTP header when a load balancer sits between the Sitecore IIS server and the client browser. I rarely encounter Sitecore implementations without load balancers, they’re critical for performance, security, resiliency during upgrades, etc. During some Sitecore testing behind the App Gateway, we observed the following message in the Sitecore logs:
Cannot parse a valid IP address from X-Forwarded-For header
About this time, a friend of mine — and another smart Sitecore guy “Bryan Furlong” — commented to me how his current project ran into port numbers in their IP addresses for xDB purposes . . . so we committed to investigating.
Using Reflector, I confirmed this specific “Cannot parse a valid IP address from” exception message appears in the Process method in the Sitecore.Analytics.Pipelines.CreateVisits.XForwardedFor class:
try
{
address = IPAddress.Parse(ipFromHeader);
}
catch (FormatException)
{
Log.Warn($"Cannot parse a valid IP address from {forwardedRequestHttpHeader} header.", this);
return;
}
It looked like the Azure App Gateway, a specific variety of load balancer for Azure implementations, includes port numbers with the IP address when relaying traffic. This port number is not handled well by the Sitecore.Analytics processing code, and — in this particular case — led to the failure of GeoIP resolution for an Azure Sitecore implementation.
To verify what was going on, I added the X-Forwarded-For field as a custom field to the IIS Logs and compared the contents.
Behind the Azure App Gateway, “X-Forwarded-For” fields in the IIS Logs show data such as:
- 50.14.232.1:45712
- 74.14.167.1:28336
By comparison, behind the other types of load balancers I looked at, the IIS Logs show data such as:
- 46.246.335.99
- 92.77.214.84
Looks like confirmation of the issue!
One cool aspect of working at Rackspace is access to lots of smart people across the industry, and we verified with the App Gateway team at Microsoft that X-Forwarded-For is a comma separated list of <I{:Port> and changing the presence of the port number is NOT currently configurable. We would need our Sitecore implementation to strip off the port portion.
The Sitecore customization to address this is fairly straight-forward. Instead of the default CreateVisit pipeline defined as follows in Sitecore.Analytics.Tracking.config . . .
<createVisit>
...
<processor type="Sitecore.Analytics.Pipelines.CreateVisits.XForwardedFor, Sitecore.Analytics">
<HeaderIpIndex>0</HeaderIpIndex>
</processor>
...
</createVisit>
. . . one must introduce their own library and override the GetIpFromHeader method to account for a port number:
public class XForwardedFor : Sitecore.Analytics.Pipelines.CreateVisits.XForwardedFor
{
protected override string GetIpFromHeader(string theHeader)
{
string[] source = theHeader.Split(new char[] { ',' });
int headerIpIndex = base.HeaderIpIndex;
string str = (headerIpIndex < source.Length) ? source[headerIpIndex] : source.LastOrDefault<string>();
if (string.IsNullOrEmpty(str))
{
return null;
}
string[] strArray2 = str.Split(new char[] { ':' }, StringSplitOptions.RemoveEmptyEntries);
if (strArray2.Length > 1)
{
str = strArray2[0];
}
return str.Trim();
}
}
In talking through this all with Sitecore support, they confirmed it’s a product bug and tracked as 132442 issue.
To ensure our custom code replaces the default Sitecore pipeline code, the following patch include file is important:
<?xml version="1.0" encoding="utf-8" ?> <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <sitecore> <pipelines> <createVisit> <processor type="Our.Custom.Namespace.And.Class.XForwardedFor,Our.Custom.Assembly.dll" patch:instead="*[@type='Sitecore.Analytics.Pipelines.CreateVisits.XForwardedFor, Sitecore.Analytics']" /> </createVisit> </pipelines> </sitecore> </configuration>
Update December 10, 2018 – I learned that Sitecore shares an official patch for this issue at https://sitecore.app.box.com/s/g9g8mu7orb3qkbc7dct2i351qaarhwes, so if you want to review their Sitecore.Support.Analytics.Pipelines.CreateVisits.XForwardedFor to address this issue, check it out.
Sitecore Architecture 