tokkonopapa

Try this one: https://gist.github.com/tokkonopapa/6a6427c0af2d58a48281987321a05746/archive/e7ca48e73e958b3d5ce03b193802b451484252c1.zip

Unzip and upload class-ip-geo-block.php into `/wp-content/plugins/ip-geo-block/classes/’.

Well, do my best on week end ??

OK. So your registration page is like https://example.com/wp-signup.php, right?

Then I’m sorry but I have to update this plugin if you turn on only “Register” at “Target actions” of “Login form” in “Back-end target settings” section.

And I also have found that this plugin has something bad for registration process of woocommerce from https://example.com/my-account (is it the default registration page of woocommerce?).

Please keep watching this topic until I complete my renovation and verification.

Thank you for your patience.

• This reply was modified 5 years, 11 months ago by tokkonopapa.
• This reply was modified 5 years, 11 months ago by tokkonopapa.

Hi @100janovic,

is the plugin compatible with Woocommerce?

Uh huh! I’ve got what you want.

I assume you have a registration page for Woocommerce. In this case, we have to think about 2 blocking target.

1. Block the registration page from being displayed
If you have https://example/registration/, then the page “/registration” should be blocked. In this plugin, a page can be configured at “Validation target” in “Front-end target settings” section.

See the topics “Buddypress registration page” and “Access from blocked country(?)“.

2. Block the request directly posted to an end point
There’s a case that the request may be posted directly to an end point without going through the registration page using some tools. Usually, the end point is wp-login.php which can be configured in “Target actions” in “Back-end target settings” that I explained in the previous thread.

But I don’t know the case of Woocommerce because I have no experience with it. If Woocommerce uses another end point to register a new user, additional consideration is needed. I’ll check it.

I added a picture that shows target actions on the online document. Please refer to https://www.ipgeoblock.com/codex/back-end-target-settings.html#login-form

Thanks for asking!

Hi @100janovic,

Did you try “Target actions” at “Login form” in “Back-end target settings” section?

is it possible to block registration only for all non-whitelist countries?

You can turn off all the target actions except “Register“.

Hi @alexlii,

I don’t have a donation account and have no plan to make it.

I’m very pleased that I can contribute to WP community.

Thank you for your concern!

Hi @glazyrindm,

Ответ – нет.

Библиотека API геолокации может обрабатывать базы данных на уровне города, используя настраиваемый фильтр, такой как “ip-geo-block-geolite2-zip-ip“. Но сам этот плагин не обрабатывает его, кроме отображения карты.

И точности бесплатных баз данных на уровне города недостаточно для определения источника доступа. Поэтому у меня нет никакого плана, чтобы поддержать это.

Hi Thomas,

Is possible this the solution?

Yes, that’s definitely the solution. It will also block the direct requests for login and registration.

Or you can specify the login page and registration page at “Validation target” in “Front-end target settings” section.

I think it’s better to specify those pages instead of specifying “All requests” (means all pages) when you configure “Content Blocking” of WP-Members because it’s human friendly.

You can give some notices on those forms for visitors from unwanted country like this:

• This reply was modified 5 years, 12 months ago by tokkonopapa.

Hi Thomas,

Thank you for clarifying your situation so detail. Now I can perfectly catch the issue.

I think the registration requests from US, RU and CN might directly access to some PHP file which can accept the requests. Those did not come through the registration form (or page) but throw the requests using some tools.

The same case happens to BuddyPress that has a dedicated registration page while it can accept a request not through the page. Currently this plugin supports only BuddyPress against that case.

I’ll investigate WP-Members Membership Plugin to check how accept the registration requests.

So I’d appreciate your patience.

P.S. Please refer to How to test prevention of attacks.

• This reply was modified 5 years, 12 months ago by tokkonopapa.

Hi Thomas,

I assume that “fake registration” means “user registration” because of your previous topics posted to WP-Members Membership Plugin forum.

I think you may login as a “fake user” via VPN while you’re login as an admin with different window but on the same browser.

In this case, a fake user could send the same cookie as admin at first access to the login page. This plugin will accespt it.

If my assumption is right, please try “Private window” on Chrome/Firefox for a fake user, or try different browser.

Hi @filout,

I’m sorry but I ca’t understand what your situation is. My questions:

1. What is “fake registration”? What is “regstrated” to where? Do you mean a domain name?

2. How did you confirm your issue? By browser? Access log on your server? or other tool?

3. How is your server configured? If your server is placed behind a reverse proxy or load balancer, you need to put an appropliate key of server environment variable in “Validation rule settings” section. See “$_SERVER keys to retrieve extra IP addresses“.

Please include as much information as possible.

Thanks for your trying my plugu!

Hi Alex,

This plugin already has:

In case of response code 40x and 50x, you can also configure “Human friendly error page“.

You can also refer to “Validation timing” to know how to make “Human friendly error page” when you select "mu-plugins" (class-ip-geo-block-mu.php) as “Validation timing“.

Hi @dater,

Sorry about the lack of documentation, and thank you for the infomation about the change of registration process of BuddyPress. I never noticed it.

Do i have to protect the (front-end) registration page of buddypress too, or is the back-end protection of the login-form enough?

You can choose either.

Please follow the instruction as below.

1. In case of enabling “Block by country” at “Login form” in “Back-end target settings” section.

In this case, the request to the registration page/process of BuddyPress can also be blocked by country.

2. In case of disabling “Block by country” at “Login form“, please enable “Block by country” at “Public facing pages” and at least specify “Register” page at “Validation target” in “Front-end target settings” section.

This also can block the requests to the registration page/process of BuddyPress.

I confirmed the above the latest BuddyPress 4.0.0 based on the documentation at Register and Activation Pages.

You can configure both 1 and 2, but internally, 1 always takes precedence over 2.

I’ll add those things into the docs.

Once I close this topic, but please feel free to ask something about your concern.

Thanks!

• This reply was modified 6 years ago by tokkonopapa.

Hi @alexlii,

I think you should also refer to the site Can I use to identify which browser’s version supports the specific HTML5/CSS3 feature.

• This reply was modified 6 years ago by tokkonopapa.