Geolocation overhaul - Testers needed

[ThierryC01]

I agree, reading helps, hence the end of my sentence: Would be great to be able to customize this within the module configuration since there are "restricted-country.tpl" files in 2 different places.

Thanks for the tip about restricted-country.tpl though.

Now, I have tested my shop using Windows 10: Firefox and MS Edge are working fine with the restrictions in place.

How about Safari then?

[datakick]

57 minutes ago, ThierryC01 said:

It should in no way display Overloaded!!

Google (and others) is using many data centers across the globe to crawl and index your site.

Guess what will happen when google access your site from a restricted country, and your server responds with standard success http page? It would index this 'This page is restricted' content instead of the real content, and that would hurt your seo efforts greatly.

That's one of the reasons why tb responds with 503 error page -- to clearly indicate to all crawlers that the content they are seeing is some sort of exception, not to be cached or indexed. 

Anyway, I don't understand the need for geo-restriction at all. If you don't want to ship to some countries then solve this at carriers / zones level. But to completely block access from these countries is overkill

 

[datakick]

4 minutes ago, ThierryC01 said:

How about Safari then?

For performance reasons the geolocation result (country code) is stored inside cookie. If you visited your site using the Safari before you turn on the VPN, it's likely the cookie contains your real country

[ThierryC01]

I did make sure to clear the cookies and the cache every time I switched countries as I had this issue too with the other web browsers. Only Safari bypasses the restrictions.

 

Geo restriction is legally required especially for countries under international embargos/restrictions depending on local laws (I am in the US). It sometimes is also best to block the shop altogether rather than allowing a customer to fill a cart and being frustrated at a restricted checkout, social medias are nowadays killers!!

Talking about testing the module itself, even with "Geolocation behavior for other countries" set to "visitors cannot see your catalog", I could actually see the catalog and proceed to an order when connected to an authorizes country. This is a feedback.

 

I will see what I can do with the carriers / zones but I am not convinced by this solution.

[hojoos]

What are the results of this testing? Where they made public anywhere? Regarding geolocation restriction, it is actually useless as everybody can use a VPN service. There are plenty of both free and paid tools. Do you agree? I believe that even schoolchildren know how to use them today. I am from https://areaphonecodes.com/united-states/503 and i see it around.

Edited May 12, 2020 by hojoos

[oliiix]

On 5/11/2020 at 10:21 PM, hojoos said:

What are the results of this testing? Where they made public anywhere? Regarding geolocation restriction, it is actually useless as everybody can use a VPN service. There are plenty of both free and paid tools. Do you agree? I believe that even schoolchildren know how to use them today. I am from https://areaphonecodes.com/united-states/503 and i see it around.

Yes geolocation isn't too precise and therefore has it's uses, but shouldn't be used for everything, it's not even legal to use it for certain things. It's all written in the maxminds usage and terms of service texts, just read. But it's not absolutely useless as you say, there are good use-cases and if people use VPN or proxy servers, they hopefully are aware of that (they would be the ones who "suffer")! As you see, most use cases have a positive impact on the user experience and are not necessary, but nice to have. If users then use VPN or proxies, they just do not get the full experience, their fault and no problem for us 😉

Edited October 15, 2020 by oliiix

[oliiix]

Quick question: Would anyone have an idea on how to access the geolocation country? I was able to convert the database to the old format and my TB accepted it. Now how can I access the geolocation country from a tpl file? I tried using {$geolocation_country} as this is being set in the front controllers geolocation management function, but it doesn't output anything. Geolocation is of course activated in the backend. I just try to output {$geolocation_country} at the top of the product.tpl somewhere just to see if it's working. Should i create a module first that gets hooked to the product page and saves the geolocation country to the config first so i can read it from the tpl file, or does such a variable already exist? I need country name or code, just some identifier.

[datakick]

First of all - you should update to bleeding edge, and install maxmindgeoip2 module that can handle new version of database. 

But back to your question - smarty variable geolocation_country is available only in restricted mode -- when tb blocked access to the store based on ip location. If user is not blocked, this variable is not populated. So you can't access it in any way.

For testing purposes you can simply modify the frontcontrolelr and always populate the geolocation_country smarty variable. 

[toplakd]

Is

On 10/15/2020 at 10:31 AM, datakick said:

For testing purposes you can simply modify the frontcontrolelr and always populate the geolocation_country smarty variable. 

Have played today with this, and I got the variable working so it displays the country

Is it possible to make such frontcontroller override, that would force language for specific country.

Or is such thing not possible just with override?

[toplakd]

Have made some testing on my test instance and solved it with using $lang_iso and $geolocation_country, however I didn't realize that I have had that country in restricted mode when saying I got it working.

$geolocation_country is still not pupulated if not in restricted as not sure where to make the change to always populate geolocation_country smarty variable 🙂

This solves my stuff testing language redirect in template.

{if $lang_iso == en  AND $geolocation_country == Bangladesh }
redirect to correct language
{/if}

 

Edited January 29, 2021 by toplakd

[AdamGunderson]

Is this module compatible with 1.3.0?

[Mark]

Been having trouble with geolocation.... I do not want to use maxmind (does it even work?) I only want to use cloudflare country headers since I know they are accurate.

Its really important that the correct country is used in the system, for managing many things, including country management with google and getting countries exactly right.

I have not figured out how to correctly use Cloudflare headers and the system is not reliably detecting user country.

I put this request https://github.com/thirtybees/thirtybees/issues/1539 in to get this fixed but in classic @datakickstyle it gets thrown out the window as an enhancement, since country accuracy doesnt seem to be anything but a bother, probably never to see the light of day and get fixed, even if it is simple to do since its just data in a header.

 

[datakick]

7 hours ago, Mark said:

Been having trouble with geolocation.... I do not want to use maxmind (does it even work?) I only want to use cloudflare country headers since I know they are accurate.

Its really important that the correct country is used in the system, for managing many things, including country management with google and getting countries exactly right.

I have not figured out how to correctly use Cloudflare headers and the system is not reliably detecting user country.

I put this request https://github.com/thirtybees/thirtybees/issues/1539 in to get this fixed but in classic @datakickstyle it gets thrown out the window as an enhancement, since country accuracy doesnt seem to be anything but a bother, probably never to see the light of day and get fixed, even if it is simple to do since its just data in a header.

You are mistaken. I have not marked this request as an enhancement. I have simply closed it as an invalid request. There is absolutely nothing to implement in thirty bees core here. Core does not know anything about individual geolocation modules, and therefore it can't check if those modules are correctly set up. That check should be responsibility of individual modules -- if not configured properly, module can simply not offer itself as an geolocation option.

Your request is basically an enhancement request for my free CLOUDFLARE GEOIP module. Thirty bees core issue tracker is not the right place to submit enhancement requests for third party modules. That's the reason why I closed the issue. Nevertheless, I copied your request to my personal to-do list. This is module that I have implemented in my free time, and I offered for free on my website to the community. As a free module, it was released "as it is". I agree that your proposed enhancement make sense. But it has very low priority, especially since most users didn't have any problems settings things up. This is not a bug in the module, it works nicely if you setup cloudflare correctly (and have no intermediate proxy that might block these http headers).

I have a big backlog of more pressing issues for my premium modules that have priority, and very little time to work on those.

If this is really a pressing issue for you maybe you could try to fix it. After all, it's just "simple to do since its just data in a header."

[nickz]

20 hours ago, Mark said:

I only want to use cloudflare country headers since I know they are accurate.

How do you know. IP are mostly dynamic and that means that an IP range from Brasil can end up in the EU a month later.

Edited January 4, 2023 by nickz

[lesley]

2 hours ago, nickz said:

How do you know. IP are mostly dynamic and that means that an IP range from Brasil can end up in the EU a month later.

That is not how dynamic IPS work in general, IP's are purchased / leased by companies and they use them. Most all ISP's are regional, so they are used in the same region / country, but dynamic to users. Where cloudflare excels with this, is they are a backbone provider. They are not looking at the IP address, they are catching the request chain and they can see where the request originated. Its because the shear amount of traffic they route they can see these things. 

[Mark]

I don't know if we will ever see thirtybees evolve beyond a one man band just doing little fixes that suit him

Some people have serious things they want to do and all that ever goes on is tinkerings without any consultation with anyone else, one guy deciding everything that suits him, ignoring anything challenging or important and just doing whatever is easy that he likes.

Thirtybees isn't a proper thing professionally managed it's just datakicks way of getting paid to do whatever he likes.

It's never had a commercial clue at any stage

Edited January 4, 2023 by Mark

[Briljander]

25 minutes ago, Mark said:

I don't know if we will ever see thirtybees evolve beyond a one man band just doing little fixes that suit him

Some people have serious things they want to do and all that ever goes on is tinkerings without any consultation with anyone else, one guy deciding everything that suits him, ignoring anything challenging or important and just doing whatever is easy that he likes.

Thirtybees isn't a proper thing professionally managed it's just datakicks way of getting paid to do whatever he likes.

It's never had a commercial clue at any stage

You must be this forums most negative person. 

If you want to get it fixed fast why don't you just pay @datakick or any other developer to do it for you? 

[Mark]

It's always been a core function of this website to determine geolocation stop making damned excuses and fix it for all

[Mark]

3 hours ago, Briljander said:

You must be this forums most negative person. 

If you want to get it fixed fast why don't you just pay @datakick or any other developer to do it for you? 

Because it's a core function for everyone not just me and always has been. Asking people to get on with things is positive in my my book, yours is obviously a shorty story not a book

[toplakd]

With installed Maxmind module its functionality is still same as it was before.

So why not use that?

[datakick]

3 hours ago, Mark said:

It's always been a core function of this website to determine geolocation stop making damned excuses and fix it for all

Again, there is NOTHING to fix here, from the thirty bees perspective.

Thirty bees / ps16 always performed geolocation using maxmind database. Because maxmind stopped supporting database version 1, we had to fix it. When we were doing that, we though that it's a good thing to make this 'detect country' functionality pluggable, instead of depending on single implementation. So we extracted it to separate maxmind geolocation module.

We support both this new module, and geolocation functionality in core core. If you use these two together, you will have the same functionality that always existed.

This new pluggable architecture allowed ME (not thirty bees) to create another module that gets the geolocation information from cloudflare. This module is mine. I made it myself, in my free time. It is new functionality. It is not part of thirty bees native modules. From thirty bees perspective, this is just ordinary module by third party developer.

You don't have any rights to go on this forum and demand changes to that module. It is absurd. It is like you creating a new issue in thirty bees project demanding changes to Panda theme. 

 

[nickz]

14 hours ago, lesley said:

That is not how dynamic IPS work in general, IP's are purchased / leased by companies and they use them. Most all ISP's are regional, so they are used in the same region / country, but dynamic to users.

I have had IP of the 190. 185 range and saw similar ip in the EU a few month later. Movistar is a gobal player, so is telekom.

[lesley]

27 minutes ago, nickz said:

I have had IP of the 190. 185 range and saw similar ip in the EU a few month later. Movistar is a gobal player, so is telekom.

Even though, with cloudflare their detection is not based on an IP list, it is based on the hops. It can see where the first hop from the ISP is, which gives away the location of the IP address.  You should do a tracert sometime and see how many hops it takes to get you to a site, and where the locations are. 

[nickz]

17 minutes ago, lesley said:

Even though, with cloudflare their detection is not based on an IP list, it is based on the hops.

Being dynamic and swapped countrywise its well possible to err. I think it is way smarter to please shoppers letting them choose the language they wish to use. Forcing a language, based on whatwhatever parameter is not really userfriendly, rather user unfriendly.

Being located in Venezuela, I'm forced to use a VPN frequently. Some US, UK pages won't open. Airtm is blocked by all local ISP also privates.

Cloudflare for most shops I guess it is an overkill. Offering 2 or more languages in shops which fight for each and every customer from just one country is totally unnecesary, IMHO.

[lesley]

12 hours ago, nickz said:

Being dynamic and swapped countrywise its well possible to err. I think it is way smarter to please shoppers letting them choose the language they wish to use. Forcing a language, based on whatwhatever parameter is not really userfriendly, rather user unfriendly.

Its been a long time since I have looked at the code around it, but here is a possible solution I have used in the past. Setting the language is easily done by detecting the browser language. When you install a browser, it installs a preferred language pack, that it also sends on requests. So you can simply set it that way. Sure, with people using VPN's you could have wrong hits, but that is an edge case, not representing the majority of users. 

I have clients (canada) that have to offer two languages unfortunately. The french in Canada are proud and require most things be both in english and french.