IP & Country Blocking, Visitor Control: setup and help

Follow the steps in Quick start.

The module installs collection, guest tracking, visitor banning and order panels as enabled. Retention is installed as 90 days. Its Configure action opens General Settings.

Saving General Settings applies the collection, guest tracking, banning, order-panel and retention choices. Default Ban Message is saved for each language and used when a matched rule has no custom message.

Set Enable Data Collection or Enable Visitor Banning to No and save to stop the corresponding function. Disable the module in Module Manager to stop both. Manage individual ban and whitelist rows through their dedicated screens.

The installed English message is:

Your access to this website has been restricted. If you believe this is an error, please contact the store administrator.

Operating system, browser, screen and raw user-agent tracking are enabled at installation. The main merchant form has no separate controls for them. Each collected record includes the IP address.

Open IP Whitelist. Enter IP Address or CIDR Range and a Label, then save. Example entries:

IP Address: 203.0.113.10
Label: Office IP

CIDR Range: 198.51.100.0/24
Label: Agency VPN

Replace these documentation addresses with your real trusted addresses. Whitelist matching happens before every ban check. A whitelisted address bypasses country, user-agent and customer bans too. Avoid broader ranges than you intend to allow. Entries are checked for the current shop or all shops where applicable.

Open Visitor Bans and add a Ban Rule. Fill at least one target. Use one target per rule when you want a predictable test: multiple target fields are alternative matches, not an all-conditions requirement.

For user-agent regexes, use /(curl|wget|python-requests)/. The matcher only recognizes a regex when its final character is /. An example ending in /i is treated as plain text in this revision. Plain text matching is already case-insensitive. User-agent strings can be changed by the visitor, so they do not establish identity.

Choose the scope

Blocking runs through actionDispatcher for native front-office controllers; module front-controller requests are skipped. The module reads the request's controller value for scoped blocking. Test your checkout and account routes, especially with custom controllers. A full-store match is checked before the narrower scope. An IP change, such as a VPN connection, can bypass an IP-only rule when the new address is outside the rule.

Examples

For a full-store test, enter the test address under IP Address, keep Ban Type as Full Block - Entire Store, enter an internal Reason, and choose a near-term Expiry Date.

For a subnet restricted to checkout, use CIDR Range 192.168.1.0/24 and Ban Type Checkout Only. For a logged-in account rule, enter Customer ID 123 and leave other targets empty. Replace sample values with the intended test data.

For a per-rule message, enter:

<p>Your access to checkout is temporarily restricted. Please contact support if you believe this is an error.</p>

Import CSV rules

Use CSV Import > Import ban rules from CSV above the bans list, choose a CSV file and click Import. Columns are positional:

ip_address,ban_type,reason
192.168.1.1,full,Fraud attempt
192.168.1.0/24,checkout,Suspicious checkout traffic
203.0.113.10,auth,Fake account attempts

The first row can be ip_address or ip headers. Slash-containing addresses go into the CIDR field. Imported rows are active, permanent and assigned to the current shop context. An unsupported ban type becomes full; an empty address is skipped. The importer does not comprehensively validate address formats. Check the resulting rows rather than treating the imported count as a successful blocking test.

The collector is added through displayHeader. After DOM readiness it waits about 1.5 seconds, then requests the generated collect URL with sw and sh from the browser's screen dimensions. With friendly routes a URL can look like:

/module/mprvisitorcontrol/collect?sw=1920&sh=1080

The browser uses the session-storage key mprvc_collected to avoid repeating the request in the same session. When storage is unavailable, collection can repeat. A fulfilled HTTP request marks the browser session even when the JSON response reports a disabled/error state. Check the actual response during testing.

The server stores IP, country, user-agent, operating system, browser/version, screen dimensions, device type, customer ID, guest ID, shop ID and record date. Login and account creation also collect through actionAuthentication and actionCustomerAccountAdd.

Collection suppresses a new row for the same customer or guest and IP when a record exists within the preceding hour. It can update screen resolution on that recent row. The data is not a complete page-view log, and Visits counts stored records rather than every page view.

Country detection uses the Cloudflare HTTP_CF_IPCOUNTRY header, then PrestaShop GeoIP, then the country cookie. The country can be empty. IP detection validates REMOTE_ADDR and accepts Cloudflare client-IP headers only from a direct Cloudflare peer. For other reverse proxies, configure the web server to restore the client address in REMOTE_ADDR.

Customer and order panels

The module renders through displayAdminCustomers and displayAdminOrder. The panel appears only when a customer has a stored record. It shows the latest IP, country, browser, operating system, screen resolution when available, device type and record date. The order page shows the customer's latest visitor record, not necessarily a snapshot from the order's creation.

With multiple stored IP addresses, IP History shows country, record count, first seen, last seen and a quick ban action. Warnings cover shared IPs, more than three countries, more than three device types and more than ten distinct IPs. Review them as indicators, not automatic bans. The customer and order panels are account-based; guest-only rows do not create a customer panel.

Check the address recorded behind a proxy

The module takes the visitor IP from PrestaShop's Tools::getRemoteAddr(); its own CF-Connecting-IP, X-Real-IP and X-Forwarded-For fallback is not used on supported PrestaShop versions. Behind Cloudflare or another proxy, configure the server to pass the real visitor address to PHP, then compare the stored visitor IP with a known test connection before relying on an IP ban.

Use a separate test address for a ban. Confirm that the matching page returns HTTP 403 and displays Access Restricted with the rule message or fallback. Confirm that an unaffected page remains available for scoped rules and that deactivation restores access.

If no visitor data appears, check that the module is enabled, the collector hook and request are present, and the endpoint returns {"status":"ok"}. Use a new browser session when the session flag already exists. Allow for the one-hour server deduplication. A very short visit can end before screen collection runs.

Confirm the saved General Settings values before testing collection, blocking or retention. If a ban does not match, check Active, expiry, shop, whitelist precedence, actual IP/country/user-agent and the selected scope. CIDR and dash ranges support IPv4. IPv6 addresses can be matched individually by their exact text.

The first storefront request after 24 hours triggers removal of records older than the active retention period, when that period is positive. You do not configure a system cron job for this daily cleanup. With no requests, cleanup waits until the next visit.

Set Enable Data Collection or Enable Visitor Banning to No and save to stop collection or blocking separately. Disable the module in Module Manager to stop both. For one rule, set Active to No instead.

Use Uninstall in Module Manager to remove it. Uninstall drops mprvc_info, mprvc_banned and mprvc_whitelist and removes this module's shared configuration and menu entries. Retain a database backup first if you need visitor history, bans or whitelist data.