Skip to main content

Access Control

Sentinel can restrict back-office access to a whitelist of IP addresses. When the whitelist is enabled, any visitor whose address is not on the list is redirected to the front-office 404 page — the admin panel simply appears not to exist.

This feature is free and available to every Sentinel user.

The same tab also holds the free, local inactive employee accounts rule, described below.

How it works​

  1. Whitelist check: On every back-office request, Sentinel resolves the visitor's real IP address (proxy and CDN aware, shared with the other protections) and compares it against the whitelist.
  2. Stealth blocking: If the address does not match any entry, the visitor is redirected to the shop's 404 page. No login form, no error message — nothing reveals that a back office exists at this URL.
  3. Checked before anything runs: the address is verified on every back-office request, before any controller executes. Credentials submitted from a blocked address are never even checked, and routes that answer with JSON or a redirect are filtered too.
  4. Logging: Every blocked attempt is recorded in the Security Logs with the event type Back Office Access Blocked, including the IP address, the requested URI and the user agent.

The front office is never affected: customers can browse and order normally regardless of the whitelist.

Settings​

The whitelist is set in the Back office IP whitelist card of the Access control tab of Sentinel > Configuration:

  • Enable back office IP whitelist: turns the protection on or off.
  • One row per address: IP or CIDR range, Comment (optional), for example "Office" or "Home VPN", and Remove, to tick to remove the address at the next save. IPv4 and IPv6 are both supported, as well as CIDR ranges such as 203.0.113.0/24 or 2001:db8::/32.
  • An empty row to add an address: IP or CIDR range and Comment (optional).
  • Save the whitelist: saves the switch and the whole list in one go.
  • Add my current IP (%ip%), where %ip% is the address you are browsing from: shown only while that address is not in the list, it saves the switch and the list with your address added.

Nothing is saved until you click one of these two buttons. Once the list is saved, the tab shows Settings have been saved.

Only an employee who can configure the Sentinel module changes the whitelist; the others see the tab read-only. See Who can change the settings.

Behind a proxy or a CDN​

If your store sits behind Cloudflare, a CDN, a load balancer or a reverse proxy, declare it in the Behind a proxy or a CDN? card of the General tab of Sentinel > Configuration before enabling the whitelist. Declaring the proxy is the only way Sentinel accepts a forwarding header: an undeclared X-Forwarded-For is ignored, because any visitor can set it and would otherwise be able to claim a whitelisted address.

Without this, every visitor reaches your server with the proxy's address:

  • whitelisting "your current IP" would actually whitelist the proxy, letting everyone through;
  • behind Cloudflare, the edge address even changes between requests, which could lock you out right after enabling.

When it detects Cloudflare or a reverse proxy that is not trusted yet in the request you are making from the back-office, that card offers Trust Cloudflare or Trust this proxy, which declares it in one click. The proxy you declare there is shared with Sentinel's other protections (brute-force, DDoS, two-factor authentication), and the card is available on every plan, free included.

Below the whitelist, the Access control tab reminds you of it, with a Declare my proxy button that opens the General tab, only shown to an employee who can configure the Sentinel module (see Who can change the settings).

The Add my current IP (%ip%) button always shows the address as the server resolves it — if that address is not the one you expect, fix the proxy configuration first.

Lockout protection​

Locking yourself out of your own back office is the main risk of this kind of feature. Sentinel checks the switch and the whole list before saving them, and refuses to save in two cases; nothing is then saved, and the card keeps what you typed so that you can correct it:

  • when an entry is neither a valid IP address nor a CIDR range: Please enter a valid IP address;
  • when the switch is on and the list holds at least one address, but none that matches the address you are browsing from: Your current IP address (%ip%) must be in the whitelist, otherwise you would lock yourself out of the back office. This refusal prevents enabling the whitelist without your address, as well as removing or changing your own address while the whitelist is on.

While the switch is on and your address is not in the list shown, the card warns you: Your current IP address (%ip%) is not in the whitelist. Add it before enabling, otherwise you would lock yourself out of the back office.

An empty list never blocks: the switch can be turned on with an empty list, but the whitelist only takes effect once it holds at least one address. Until then, the card says No IP address yet. The whitelist only takes effect once at least one address is added.

Command-line access (bin/console) is never restricted.

If you still end up locked out (for example, your ISP changed your IP address), delete the SENTINEL_BO_WHITELIST_ENABLED value from the ps_configuration table, or ask your hosting provider to do it:

DELETE FROM ps_configuration WHERE name = 'SENTINEL_BO_WHITELIST_ENABLED';

Good practices​

  • Prefer CIDR ranges over single addresses if your ISP does not provide a fixed IP.
  • Add a comment to every entry so you know later why it was added.
  • If your team works remotely, consider routing back-office access through a VPN with a fixed egress IP and whitelisting only that address.

Inactive employee accounts​

Open Sentinel > Configuration > Access control, then Inactive employee accounts. The rule is off by default. Turn on Deactivate inactive employee accounts, choose the Days without using the back office (1 to 3650, 90 by default) and save. Changing it requires the permission to configure Sentinel and permission to edit employees. The rule applies to employees of every shop.

Which accounts are deactivated?​

Sentinel relies on the last connection date that PrestaShop records for each employee: it is updated the first time the employee uses the back office each day, whether they just signed in or are still signed in. An account is deactivated once that date is more than N days old. An account created while the rule is on counts from its creation.

The check runs at most once a day, when someone uses the back office: without back-office navigation, nothing runs. Front-office visits do not trigger it.

When you enable the rule​

When enabling, the card offers to also deactivate right away the accounts already inactive for longer, including those that never logged in. Before this version of Sentinel, PrestaShop did not record the date on some of its back-office pages: an employee who only used those pages may look inactive, so check the Employees page before choosing it. Without this choice, every account first gets the full delay from the activation day, so nobody is deactivated before N days.

While the rule is on, an account you reactivate by hand from the Employees page also gets a new delay of N days from its reactivation.

Keeping accounts and access​

The last active SuperAdmin is never deactivated: if every SuperAdmin is inactive, the most recently used one stays active.

Deactivation prevents back-office login but keeps the account, its data, profile and permissions. Reactivate it from PrestaShop's Employees page. Sentinel never deletes an account.