We have an EPiServer CMS application (v.10.10.4.0) that we host in azure (one staging and one production environment). They are setup to use ssl bindings.
I've done the following in both our environments:
We're using the GeoLocationProvider that is shipped with EPiServer to try to personalize content.We're filtering out content by using ContentArea.FilteredItems.
When I VPN to an NA server I can see that that the personalization is working in production, but it fails to do so in our staging environment. So I guess you'll be saying that there's a diff in our setup right? But I've checked every setting and it's the same as our production site (except host names, bindings etc - staging doesn't use www prefix). The code and EPiServer version is the same in both environments. The config is the same (except connectionStrings). So what am I missing?
Should the GeoLocation work (out of the box) or is there something else I need to setup in config/code to get this working? Is there like a magic button in the CMS admin I forgot to press?
I'm guessing that one part of the answer lies in the FilteredItems property, so if anyone has some deep knowledge about how the underlying code works (GetFilteredFragments, ISecurityDescriptor, IRoleSecurityDescriptor) I'd be very interested in reading your input.
You could add a some analysis code and do IGeolocationResult loc = Geolocation.Provider.Lookup(ip);
Check which IP is returned for both environments using
Request.ServerVariables["HTTP_X_FORWARDED_FOR"] & Request.ServerVariables["REMOTE_ADDR"]
You could also lookup location using some other source than the included database and compare results.
Thanks for your swift reply. I tried logging both of those variables and they are the same in both staging and production. The X_FORWARDED_FOR contained a port number.I wrote my own GeoLocationProvider (overriding GeolocationProviderBase) to try and see if it was something wrong with the accurcy in the GeoLite db, but this does not seem to be the case. The DB returns the correct geo information about my IP. I've also tried checking the result of isMatch and IsPrincipleInGroup:var visitorGroupRoleRepository = ServiceLocator.Current.GetInstance<IVisitorGroupRoleRepository>();VisitorGroupRole roleProvider; visitorGroupRoleRepository.TryGetRole("North America - Geo location", out roleProvider);var isMatchUsa = roleProvider.IsMatch(HttpContext.User, new HttpContextWrapper(System.Web.HttpContext.Current));var visitorGroupRoleRepository = ServiceLocator.Current.GetInstance<IVisitorGroupRoleRepository>(); var user = HttpContext.User; var vgHelper = new VisitorGroupHelper(visitorGroupRoleRepository); var isInGroupUs = vgHelper.IsPrincipalInGroup(user, "North America - Geo location");Both of these returns false in staging environment but true in the production environment. Any other advices?
Im reporting same problem on some environments and would like to know if a speacial setting is needed of rthis geo location criteria to work with visitors group-What do i need for this to work in a local alloy site project?
Hi nitinanand - It was a silly mistake from my side that caused the geo location to fail. Not having much experience using the visitor group tab I did not see the that the matching criteria was set to "ALL". Based on my criteria, that meant that the user would have to be in North America AND South America to match the group criteria. The result was always false. Setting the operator to ANY solved my issue. Also you should double check that the GeoLiteCity db is in your App_Data folder in the failing environment?
good you saw that. I am trying to fix visitor group with only one criteria Geo Location and its not working. Not even on alloy project. I updated GeLiteCity.dat as well but nothing works.
Can you tell me something more about your environment/solution? You say you think it could be environment specific - in which environment is it failing? And what's the difference between this environment/solution setup and the one that's working? Geolocation will not work when running the solution on localhost (127.0.0.1 - does not exist in the ip lookup table).
thanks Christian, I m trying on 127.0.0.1 localhost. is it possible to make it work on localhost? You think geo coordinate criteria can work on localhost?
To your first question:- We have 2-3 environments of a project and i am trying to differentiate why Geographic location criteria only works on one and not on other 2. Is it something to do with epi version. All 3 env are epi 10
If you want to add support on localhost you could try a solution similar to https://www.patrickvankleef.com/2015/06/07/using-dojo-when-creating-a-custom-visitor-group/ (see the heading "IP address resolver"). Can you impersonate the visitor group while being logged in to EPiServer?
You said you updated the GeoLiteCity.dat - have you done the same in all environments? Are you using the legacy version of the GeoLiteCity db or have you upgraded to GeoLite2-City db?
I would also recommend that you log the server variables HTTP_X_FORWARDED_FOR and REMOTE_ADDR as suggested by Johan Kronenburg just to ensure that the the headers are set correctly.
I'm using the leagcy version with the updated files downloaded from maxmind but still geo location criteria seems not working at all.
Hi - any resolution to this yet?
I'm on a Epi CMS version 9.7.1 - upgraded from version 8 and having the same issues. Not being able to use Geolocation.Provider.Lookup(myStaticIPValue) returns null.
I have recently updated the GeoLiteCity.dat -file but that did not work either.
Update: Now Lookup returns an actual object (web.config was not pointing to the GeoLiteCity.dat correctly), however the Region property is null. Country is correct, and its Region property is use in a personalization of blocks.
Try using VPN services. Here's the one I prefer Mlwebtechnologies.