[TylerAustin] adminCP Firewall - XF2 1.0.0

Allowed IP Rules​

Enter one rule per line. Supported examples include:

• Exact IPv4: 203.0.113.25
• IPv4 CIDR: 203.0.113.0/24
• Legacy IPv4 prefix: 203.0.113.
• Exact IPv6: 2001:db8::25
• IPv6 CIDR: 2001:db8::/48

IPv4-mapped IPv6 addresses are compared as IPv4. Mapped CIDR prefixes from /96through /128 convert to IPv4 prefixes from /0 through /32; for example, ::ffff:203.0.113.25/120 becomes 203.0.113.0/24. Mapped CIDRs shorter than /96 are rejected. IPv4 and IPv6 ranges are otherwise evaluated separately. Use /0 with care: 0.0.0.0/0 permits every IPv4 address and ::/0 permits every IPv6 address in that comparison family. A mapped IPv6 /96 also becomes IPv4 /0, permitting every IPv4 address. These valid rules remove the IP-based restriction for the covered family; do not use them when you intend to trust only a limited network. Loopback requests from 127.0.0.0/8 and ::1 are always accepted so local environments such as MAMP Pro remain accessible. When IP denial is enabled, the allowlist also applies to existing administrator sessions. An IP change or removal of the current IP from the allowlist takes effect on the next AdminCP request. Normal logout remains available. Use the emergency config.php bypass below if you need to recover access. These request checks do not generate additional login notifications. Blocked AdminCP pages and overlays display the same structured recovery guidance as the login page, with a separate recovery command and narrow-screen wrapping. IP decisions use XenForo's native request IP. If a reverse proxy makes every request appear to originate from loopback, the localhost exception will also apply to those requests. Configure the web server/proxy to expose the verified client address correctly before relying on IP restrictions. Do not trust arbitrary client-supplied forwarding headers or use a hostname/geolocation lookup as an access rule.

Settings Change History​

Use Firewall settings change history on the Firewall settings page to review who changed a setting, when it changed, and its previous and new values. Access requires Manage AdminCP Firewall, the same administrator permission used to manage the settings. Logging is automatic while the add-on is active, even when the firewall itself is bypassed or disabled; there is no logging toggle. Unchanged saves are not logged. History begins after this feature is installed and follows XenForo's standard change-log retention. Direct edits to src/config.php are not recorded. Firewall settings and access-check forms mark their allowlist, recipient-list, checked-address, and protected option-default fields for XenForo's native request-log masking. New request payloads mask these submitted values, including server-error POST data; the dedicated settings history retains old and new values behind Manage AdminCP Firewall. Existing log records and XenForo's normal request metadata and retention remain unchanged.

Notifications​

Administrator status is checked again at final login completion, including passkey sign-ins and pending two-step logins. Accounts that no longer have administrator status are rejected before Firewall invalid-IP or successful-login notifications and before the native completion routine changes the logged-in user. Each event can be enabled independently. The Enable email notifications and Enable alert notifications switches select its delivery channels. When enabled, alerts are delivered to administrators who have the Manage AdminCP Firewall permission, and emails go to the configured recipient list or, if that list is empty, eligible managing administrators' account addresses. Disabling both channels stops notifications, not IP protection or settings change history. Administrator email fallback applies only to an empty saved recipient list. If a nonempty saved list contains no valid addresses, email delivery is skipped and a diagnostic is logged without including the recipient values. Save a valid list, or clear it to use eligible administrator addresses. Alert delivery remains independent. Notification delivery failures are logged without preventing XenForo's normal login response. Incomplete password forms and malformed or expired passkey preparation requests do not generate failed-login notifications. Failed passkey attempts are identified as passkey sign-ins rather than attributed to a submitted account name that has not been verified. The failed attempt that reaches a notification cutoff remains eligible for its configured notification. Later attempts that are already limited are suppressed; XenForo retains control of authentication and lockout responses.

Optional Recently Used Devices Integration​

When Recently Used Devices 2.5.3 or newer is active, its Check AdminCP logins option is enabled, and Integrate with Recently Used Devices is enabled in AdminCP Firewall, firewall notifications can include the current device record supplied by the add-on's native device repository. The integration includes only notification-relevant context: device name, browser, operating system, device type, authorization state, authentication method, approximate city/country, recorded device IP, and device login time. It does not include session IDs, browser tokens, approval tokens, device codes, precise coordinates, or raw user-agent values. Successful-login notifications are sent after XenForo's complete AdminCP login action has returned, allowing Recently Used Devices to finish its own device logging regardless of class-extension order. If no matching device record is available, the normal firewall notification is sent without a device section. Successful-login notifications also cover automatic AdminCP login after a device approval, including approvals completed through the login form. If Recently Used Devices administrator device management is enabled, notifications include its native AdminCP user-device URL. Access to that page remains controlled by Recently Used Devices' own administrator permissions. Disabling the integration option, disabling Recently Used Devices' AdminCP tracking, deactivating that add-on, or uninstalling it safely returns AdminCP Firewall to standalone behavior. No Recently Used Devices class, entity, finder, repository, option, or route is accessed unless the compatible add-on is active.

Optional XenConcept Admin Login Log Integration​

When XenConcept Admin Login Log 2.0.1 or newer is active and Integrate with XenConcept Admin Login Log is enabled, AdminCP Firewall uses that add-on's native repository and finder to locate the matching recent login-log record. Failed firewall events correlate with failed records; successful and invalid-IP events correlate with success records because the latter have valid administrator credentials. Matching is intentionally narrow: the event state, packed IP address, user ID (or submitted login when no user is known), and the 30 seconds ending at lookup time must agree. The lookup uses the same clock source as XenConcept's record timestamps and excludes future-dated records. A matched record adds its state, login, IP, recorded time, and native Admin Login Log AdminCP link to alerts, push notifications, and emails. The integration is read-only and never clears or modifies XenConcept records. The submitted login is kept unchanged for record matching. Cleaning and shortening the name shown in a Firewall notification does not change which login the lookup searches for. This is recent supporting context, not a unique identifier for the current attempt. XenConcept records its primary-password result before the remaining login chain finishes; a recorded success does not establish that two-step verification, device approval, or the firewall subsequently permitted access. Its supplied version does not directly log passkey or two-step completion. The Firewall's own event remains the outcome being reported. Lookup input must be a valid IP literal. The supplied XenConcept version uses a legacy encoder that can store some four-character IPv6 literals as the same bytes as a different IPv4 address. The Firewall omits companion context for either side of those ambiguous encodings rather than show or correlate a misleading IP. The Firewall's own allowlist checks and notifications remain available, and no historical companion records are rewritten. The adapter also omits context when a supplied IPv6 address outside the genuine IPv4-mapped range :ffff:0:0/96) would be reduced to IPv4 by that encoder. Genuine mapped addresses remain supported. A historical record that already discarded its original IPv6 prefix cannot be repaired or uniquely attributed from the stored IP bytes alone; matching remains supplementary context, not proof of the original client address. If no matching record is found, the normal firewall notification is sent without a login-log section. Disabling the integration option, deactivating XenConcept Admin Login Log, using a version older than 2.0.1, or uninstalling it safely returns AdminCP Firewall to standalone behavior. No XenConcept entity, finder, repository, or route is accessed unless the compatible add-on is active.

Emergency​

Add one of the following entries to XenForo's src/config.php when an emergency override is required: $config['enableAdminCPFirewall'] = false; // Temporarily bypass the firewall. $config['enableAdminCPFirewall'] = true; // Force the firewall on. Remove the entry to return control to the AdminCP Firewall enabled option. Boolean values are recommended; common string and numeric boolean values are also recognized.