Download the PHP package kanopi/firewall without Composer

Lite Firewall

Lite Firewall is a powerful, extensible request-evaluation library for PHP-based systems. It provides comprehensive protection by analyzing HTTP requests and applying configurable rules to either allow or block access based on IP addresses, geolocation, user agents, URLs, ASN (Autonomous System Numbers), and rate limits. The library is designed to work seamlessly with popular frameworks like Drupal, WordPress, Symfony, or any standalone PHP application.

Table of Contents

• Features
• Requirements
• Installation
• Quick Start
• Configuration Overview
• Configuration Loading & Includes
• Environment Variables in YAML
• Global Configuration
  • Multiple Offenses Defense
• Storage Configuration
• Plugin Architecture
  • Challenge Response Type
• Available Plugins
  • IP Address Plugin
  • GeoLocation Plugin
  • URL Plugin
  • User Agent Plugin
  • ASN Plugin
  • Rate Limit Plugin
  • Vulnerability Score Plugin
  • CRS (OWASP Core Rule Set) Plugin
• Conditional Logic
• Logging Configuration
• Dynamic Configuration Overrides
• Platform Integration
• Advanced Examples
• Testing
• Legacy format (deprecated)
• Contributing

Features

• Flexible Plugin System: Modular architecture allows for easy extension and customization
• Multiple Storage Backends: Support for in-memory, file-based, database, and Redis storage
• Comprehensive Request Analysis: Evaluate requests based on IP, location, user agent, URL patterns, and more
• Vulnerability Scoring: Advanced risk assessment based on multiple factors with configurable thresholds
• Rate Limiting: Built-in rate limiting with configurable storage backends
• GeoIP Integration: Full support for MaxMind GeoIP2 databases (both local and web service)
• Advanced Conditional Logic: Support for simple, complex, and grouped conditional rules
• Remote Configuration Support: Load configuration files from remote URLs with local caching
• PSR-3 Compatible Logging: Integration with Monolog for flexible logging
• Framework Agnostic: Works with any PHP application or framework

Requirements

• PHP 8.1 or higher
• Composer
• Optional: MaxMind GeoIP2 databases for geolocation features
• Optional: Redis for distributed rate limiting

Installation

Install via Composer:

Quick Start

Basic Implementation

Place the following code in your application's entry point (e.g., index.php, wp-config.php, or Drupal's settings.php):

⚠️ Important: Configure trusted proxies before calling Firewall::create()

Every plugin in this library evaluates $request->getClientIp(). Symfony only honors X-Forwarded-For / Forwarded / X-Real-IP when the integrator has called Symfony\Component\HttpFoundation\Request::setTrustedProxies(...). If your application sits behind a load balancer, CDN, or reverse proxy and you skip this step, attackers can spoof their source IP via X-Forwarded-For and bypass IP/CIDR allow-lists, block-lists, and per-IP rate limits.

When trusted proxies are not configured, Firewall::create() logs a warning to the configured logger. To make a missing trusted-proxies setup a hard startup failure instead, set global.require_trusted_proxies: true in your config — the library will then throw ConfigurationException rather than start in a spoofable state.

Minimal Configuration Example

Create a config/firewall.yml file:

Test Drive

Follow these steps to quickly test Lite Firewall locally in a clean environment:

🧪 Quick Test Drive Setup

1. Create a temporary folder

2. Install Lite Firewall via Composer

3. Create a basic firewall.yml configuration

4. Create an index.php file

5. Start a PHP built-in web server

6. Open your browser and test

   • Visit http://localhost:8000 — you should see:

   • Visit http://localhost:8000?block=1 — you should see:

   • Visit http://localhost:8000 — you should see:

This simple example demonstrates how the firewall intercepts requests using YAML configuration and shows how easy it is to add rule-based blocking.

To start over empty the contents of the Storage file

Configuration Overview

The firewall configuration consists of five main sections:

Legacy formats bypass: / block: are still accepted and auto-normalized into plugins: entries at load time. See Legacy format (deprecated) at the end of this document. New configs should use the plugins: array.

Configuration Loading & Includes

The firewall supports modular configuration via a top‑level configs: key in any YAML file. Paths listed under configs: are loaded and merged into the current file.

Rules & behavior

• Paths in configs: can be:
  • Relative (resolved against the directory of the YAML file that declares them)
  • Absolute
  • Remote URLs (e.g., https://example.com/firewall-rules.yml; cached locally with configurable TTL)
  • Use the {config_dir} token (expanded to the current YAML's directory)
  • Glob patterns (e.g., more/*.yml; matched files are sorted alphabetically)
  • Environment-driven using %env(...)% (must resolve to a string path)
• Merge semantics:
  • Objects (associative arrays) are merged deeply; later files override earlier keys
  • Lists (numeric arrays) are replaced as a whole by later files
• Safety: circular includes are prevented and excessive include depth is rejected.

Remote Configuration Files

Configuration files can be loaded from remote URLs, which is useful for centralized management across multiple servers:

Remote files are cached locally to improve performance and reduce external dependencies. You can control caching behavior using PHP constants:

Example

In the example above, the log file and GeoIP database paths are relative to the YAML file (not the PHP current working directory). This makes configs portable regardless of where your app bootstraps from.

Environment Variables in YAML

You can reference OS environment variables inside YAML using Symfony‑style tokens: %env(NAME)%.

• When a YAML scalar is exactly a single token (e.g., port: '%env(int:APP_PORT)%'), the value is returned as a native type based on the processor (int, float, bool, array, or string).
• When a token appears inside a larger string, it is interpolated as text.
• Remember to quote tokens in YAML (e.g., ' %env(...)% ') because % is a reserved indicator in YAML.

Variable Resolution with $_SERVER Fallback

The firewall checks environment variables in the following order:

1. getenv() - PHP environment variables (set via putenv(), shell environment, or PHP-FPM/Apache configuration)
2. $_SERVER - PHP superglobal (fallback when getenv() returns false)

This fallback behavior is particularly useful in web contexts (Drupal, WordPress, Symfony, Laravel) where configuration is often stored in $_SERVER by the web server or application framework.

Example use case: Nested Array Keys

Important: When extracting nested keys from JSON, you must chain key: processors for each level of nesting. For example, to access obj.a.b.c, use: json:key:a:key:b:key:c:VAR_NAME.

Priority: When a variable exists in both getenv() and $_SERVER, getenv() takes precedence. This allows you to override server-level configuration with environment-specific values.

Supported processors (can be chained left→right):

• Type Processors: string, int, float, bool, json (→ array), base64
• File Operations: file (reads file contents), resolve (resolves relative paths)
• String Operations: trim, lower, upper, urlencode, urldecode
• Array/List Operations: csv (→ list), query_string (→ array, preserves duplicate keys), url (→ array from parse_url)
• Special Processors:
  • default:value - Provides fallback value if variable doesn't exist
  • defined - Returns boolean indicating if variable exists
  • const - Retrieves PHP constant instead of environment variable
  • key:name - Extracts a key from an array (chain multiple for nested keys)
  • not - Logical NOT (negates boolean value)

Examples

Path resolution for common keys

Some metadata values are commonly file paths. The loader automatically rewrites relative values to absolute when they exist on disk, using the YAML file's directory as the base. You can target keys with dot‑path patterns and lightweight alternation:

• * matches any key at that level
• Alternation per segment: block|allow, {block,allow}, or (block|allow)

Useful patterns

With these patterns, paths like logs/app.log, geo/GeoLite2-ASN.mmdb, or limits/rate.yml will be resolved relative to the YAML file and stored as absolute paths at runtime.

Global Configuration

The global configuration allows for items like the default status code and the default block message template to be configured. More options to come.

Trusted Proxies

require_trusted_proxies controls how Firewall::create() reacts when Symfony\Component\HttpFoundation\Request::getTrustedProxies() is empty:

See the trusted-proxies note in Basic Implementation for the Request::setTrustedProxies(...) call you need to add before Firewall::create().

Mode

The mode setting controls how the firewall responds when a request is matched by a blocking plugin. Defaults to block if not specified.

• block — Default production behavior. Blocked requests receive an HTTP error response and the script exits.
• log — Useful for dry-run/audit deployments. Plugins are evaluated normally, but blocks are only logged (at warning level) without stopping the request or recording offenses in storage.
• exception — Throws a Kanopi\Firewall\Exception\FirewallBlockedException instead of calling exit(). The exception carries the status code (via getStatusCode()) and banning message, allowing host frameworks (Laravel, Symfony, etc.) to catch and handle it with their own error responses.
• disabled — Bypasses the firewall entirely. No plugins are evaluated and the request is immediately allowed. Useful for maintenance or feature-flag toggling.

Status Code

The status code of the default message can be defined here. By default, it sets it to 400 but can be set to something else if it is needed.

Banning Message

The banning message can be configured and dynamically replaced with placeholders. Examples of placeholders can be found below.

Multiple Offenses Defense

Some storage plugins can track multiple offenses from the same attacker over time. You can control how blocking escalates by using the blocking_escalation configuration setting.

Below is an example of how to configure it:

Each escalation rule includes the following:

• window – Time period in seconds to look back for offenses (e.g., 300 = 5 minutes).

• offense – Number of offenses required during the window to trigger the rule.

• duration – How long to ban the client (in seconds).

  • Use 0 for a permanent ban.

  • If duration is not set, the plugin's default ban duration will be used.

This system lets you gradually increase penalties for repeat offenders, starting with temporary bans and escalating to permanent blocks if necessary.

Storage Configuration

Storage defines how the firewall persists blocked IP addresses across requests.

Available Storage Classes

1. In-Memory Storage

Non-persistent storage that resets with each request. Useful for testing.

2. File Storage

Persists blocked IPs to the filesystem.

3. Database Storage

Stores blocked IPs in a SQL database using Doctrine DBAL.

Plugin Architecture

Plugins are the core components that evaluate incoming requests. They are configured as an ordered list under the top-level plugins: key. Each entry declares one plugin instance and its response mode — either allow (let the request through), block (reject the request), or challenge (require the visitor to solve an interstitial before continuing).

Common Plugin Configuration

All plugin entries share the same shape:

The same class can appear multiple times in the list — each entry becomes its own plugin instance, so you can split rules across instances with different weights or response modes.

YAML Syntax Note: The plugin: value must be quoted with double backslashes:

• ✅ Correct: plugin: "Kanopi\\Firewall\\Plugins\\IpAddress"
• ❌ Wrong: plugin: Kanopi\Firewall\Plugins\IpAddress (missing quotes and single backslash)
• ❌ Wrong: plugin: \Kanopi\Firewall\Plugins\IpAddress (leading backslash)

This also applies to all type: declarations (storage backends, rate limit storage).

Plugin Execution Order

The firewall evaluates response: allow entries first (sorted by weight, lower runs first). If any allow plugin matches, the request is permitted immediately and no other plugins run. Otherwise:

1. response: challenge entries run next. If one matches and the visitor does not already hold a valid pass token, an interstitial is served and the request is paused until the challenge is solved.
2. response: block entries run last and the first match rejects the request.

A valid pass token (set by a previously solved challenge) short-circuits the challenge bucket but does not suppress block plugins. See Challenge Response Type below.

Suggested weight ranges:

• -200 to -100: Early filters (IP allow-lists, trusted networks)
• -99 to -1: Security checks (geo-blocking, ASN filtering)
• 0: Default (URL rules, user agent checks)
• 1 to 100: Post-evaluation (rate limiting, logging)

Example: Layered Security

Challenge Response Type

response: challenge serves an interstitial (a CAPTCHA-style proof-of-effort page) when a plugin matches, instead of rejecting the request outright. A visitor who solves the challenge is issued an HMAC-signed pass token that short-circuits any future response: challenge plugin until the token expires.

The pass token is:

• Signed with the configured challenge.secret (HMAC-SHA256) so it cannot be forged.
• IP-bound — the token only verifies for the same client IP that solved the challenge.
• Delivered two ways — as an HttpOnly; Secure; SameSite=Strict cookie and as a value the interstitial JS writes to localStorage so SPA callers can attach it to XHRs via a custom header (defaults to X-Firewall-Challenge).
• Expires after metadata.default_expiration_time seconds for the matched plugin (default 3600).

Minimum configuration

If any plugin uses response: challenge, challenge.secret is required. Startup fails fast with ConfigurationException when it is empty — the firewall will not silently fall back to plaintext tokens.

Built-in provider

The math provider asks "What is A + B?" with single-digit operands. It's a low-friction proof-of-effort, not a CAPTCHA. For stronger bot resistance, implement Kanopi\Firewall\Challenge\ChallengeProviderInterface (Turnstile, hCaptcha, reCAPTCHA, etc.) and set challenge.provider to its FQCN.

How dispatch interacts with allow / block

Loading External Plugin Configuration

Plugins can load rules from external files (local or remote) using the metadata.config option. This is useful for managing large rule sets separately:

The external files use the same structure as the inline config section. Multiple files can be specified and will be merged in order. Both local file paths (relative or absolute) and remote URLs are supported.

Available Plugins

IP Address Plugin

Namespace: \Kanopi\Firewall\Plugins\IpAddress

Evaluates requests based on IP addresses, supporting IPv4, IPv6, CIDR blocks, and IP ranges.

Configuration Example

GeoLocation Plugin

Namespace: \Kanopi\Firewall\Plugins\GeoLocation

Evaluates requests based on geographic location using MaxMind GeoIP2 databases.

Configuration Example

Available Variables

• country - Returns country ISO code (e.g., "US")
• country.isoCode - Country ISO code
• country.name - Full country name
• continent - Returns continent code (e.g., "NA")
• continent.code - Continent code
• continent.name - Full continent name
• city - Returns city name
• city.name - City name
• location.latitude - Latitude coordinate
• location.longitude - Longitude coordinate
• location.timeZone - Time zone
• postal - Returns postal code
• postal.code - Postal/ZIP code

URL Plugin

Namespace: \Kanopi\Firewall\Plugins\Url

Evaluates requests based on URL components and request parameters.

Configuration Example

Available Variables

• method - HTTP method (GET, POST, PUT, DELETE, etc.)
• host - Hostname from the request
• path - URI path (e.g., /admin/users)
• scheme - URL scheme (http or https)
• port - Port number
• query.* - Query parameters (e.g., query.page, query.id)
• post.* - POST body parameters
• header.* - HTTP headers (e.g., header.user-agent)
• cookie.* - Cookie values

User Agent Plugin

Namespace: \Kanopi\Firewall\Plugins\UserAgent

Analyzes user agent strings to identify bots, devices, browsers, and operating systems.

Configuration Example

Available Variables

• bot - Whether the user agent is a bot ("true" or "false")
• device.type - Device type (desktop, smartphone, tablet, etc.)
• client.name - Browser or client name
• client.type - Client type (browser, mobile app, etc.)
• client.version - Client version number
• os.name - Operating system name
• os.short_name - OS short name (WIN, MAC, LIN, etc.)
• os.version - OS version number
• brand - Device brand (Apple, Samsung, etc.)
• model - Device model

ASN Plugin

Namespace: \Kanopi\Firewall\Plugins\Asn

Evaluates requests based on Autonomous System Numbers (ASN) using MaxMind's GeoIP2 ASN database.

Configuration Example

Available Variables

• asn - Autonomous System Number
• asn_org - Organization name associated with the ASN

Rate Limit Plugin

Namespace: \Kanopi\Firewall\Plugins\RateLimit

Implements rate limiting to prevent abuse and DDoS attacks.

Configuration Example

Path Patterns

• Exact match: /login
• Wildcard: /api/* (matches /api/users, /api/posts/123, etc.)
• Regex: /^\/api\/v[0-9]+\// (matches /api/v1/, /api/v2/, etc.)

Vulnerability Score Plugin

Namespace: \Kanopi\Firewall\Plugins\VulnerabilityScore

Evaluates requests based on a comprehensive scoring system that combines multiple risk factors to determine if a request should be blocked. This plugin provides fine-grained control over security policies by assigning scores to various request characteristics and blocking based on cumulative risk levels.

Key Features

• Multi-Factor Scoring: Evaluates HTTP methods, geographic origin, ASN, patterns, and user agents
• Configurable Risk Levels: Define custom thresholds with different blocking behaviors
• Pattern Detection: Built-in detection for SQL injection, XSS, command injection, and custom patterns
• Geographic Intelligence: Optional integration with GeoIP databases for country and ASN scoring
• Dynamic Response: Different status codes and expiration times based on risk level

Configuration Example

Scoring Components

1. Method Scoring

Assigns scores based on HTTP methods, with higher scores for potentially dangerous operations.

2. Country Scoring

Uses GeoIP database to identify request origin and assign scores based on geographic risk assessment.

3. ASN Scoring

Evaluates the Autonomous System Number of the request origin, identifying datacenter, VPN, or residential connections.

4. Pattern Detection

Searches for malicious patterns in various parts of the request:

• Locations: uri, query_string, body, headers
• Types: regex, contains, exact
• Patterns: SQL injection, XSS, command injection, path traversal, etc.

5. User Agent Analysis

Identifies and scores suspicious or malicious user agents, including security tools and bots.

Risk Levels

Each risk level can be configured with:

• threshold: Minimum score to trigger this level
• block: Whether to block requests at this level
• status_code: HTTP status code to return when blocking
• expiration_time: How long to block the IP address (in seconds)

Advanced Usage Examples

Example 1: E-commerce Site Protection

Example 2: API Protection

Example 3: Geographic Restrictions with Exceptions

Integration with Other Plugins

The VulnerabilityScore plugin works well with other firewall plugins:

Performance Considerations

• The plugin evaluates all scoring factors for each request
• Pattern matching can be CPU intensive with many patterns
• Consider using Redis or database storage for better performance at scale
• Place the plugin after basic filters (like IP blocking) for efficiency

Debugging and Monitoring

The plugin logs detailed information about scoring decisions:

Log entries include:

• Total score calculated
• Individual component scores
• Risk level determined
• Blocking decision

CRS (OWASP Core Rule Set) Plugin

Namespace: \Kanopi\Firewall\Plugins\Crs

Evaluates each request against the OWASP Core Rule Set — the same ruleset that powers ModSecurity, Coraza, and most commercial WAFs. Detects SQL injection, XSS, LFI, RFI, RCE, PHP / Java injection, session fixation, protocol-level attacks, and known scanner traffic. Backed by the kanopi/crs-engine composer package, which parses CRS source files into a runtime-optimised cache and refreshes weekly from upstream.

Key Features

• Real CRS rules: Parses the upstream REQUEST-*.conf files directly — no hand-translation, no divergence from CRS behavior.
• Paranoia levels (1-4): Trade detection coverage against false-positive rate the same way CRS deployments tune ModSecurity.
• Per-rule / per-category disable: Silence known false positives without touching upstream rule files.
• Monitor vs block modes: Roll the plugin out in monitor mode first; the firewall logs what would have been blocked without rejecting traffic.
• In-process rule cache: ~3-4 ms per request once warm (FPM worker steady state). Zero extension dependencies — no APCu / OPcache preload required.
• Auto-refreshed rules: The crs-engine package CI fetches new CRS releases weekly and opens a reviewable PR; composer update pulls the latest curated bump.

Configuration Example

Coverage

Currently the plugin handles request-side evaluation: every CRS rule in REQUEST-*.conf runs against the incoming request. Response-side rules (RESPONSE-* files — SQL error / stack-trace / PHP warning leakage detection) are tracked under issue #69 and will land as a follow-up.

The four CRS rules that rely on libinjection (@detectSQLi / @detectXSS — rules 941100, 941180, 942100, 942500) are parsed but not evaluated; the engine logs them as parser warnings in vendor/kanopi/crs-engine/rules/manifest.json. CRS's regex-based SQLi/XSS rules in the same files run normally and provide the bulk of the detection.

What gets logged

Blocked requests log at info level with full context:

• rule_id — the CRS rule that fired the block
• total_score — accumulated anomaly score
• scores — per-category breakdown (sqli, xss, lfi, etc.)
• matched_rule — the rule's human-readable message
• matched_data — the substring of the request that matched

Non-blocking matches (monitor mode, or rules whose action is pass) log at debug level.

Conditional Logic

The firewall supports three formats for defining conditions:

1. Simple Format

Quick and readable syntax for common conditions:

Supported Operators

• equals (default)
• not_equals
• contains
• starts_with
• ends_with
• regex
• in
• greater_than (>)
• less_than (<)
• greater_than_or_equal (>=)
• less_than_or_equal (<=)
• exists

2. Complex Format

Detailed configuration with full control:

3. Grouped Format

Combine multiple conditions with logical operators:

Logging Configuration

The firewall uses Monolog for flexible logging, so any Monolog handler can be wired up through the logger key. Each entry under logger is a separate handler — combine as many as you need (file + Slack + email is a common pattern).

Each handler entry accepts:

• class — fully qualified handler class name (must implement Monolog\Handler\HandlerInterface).
• args — positional constructor arguments, in order.
• formatter (optional) — class + args for a Monolog\Formatter\FormatterInterface implementation, applied to that handler.

Log levels are passed as strings like Monolog\Level::Info (Debug, Info, Notice, Warning, Error, Critical, Alert, Emergency). Relative log file paths (e.g., args[0] for StreamHandler) are resolved relative to the YAML file that declares them.

Heads up: several Monolog handlers require additional PHP extensions or third-party packages. Slack/IFTTT/Pushover/Telegram need ext-curl; SendGridHandler and SymfonyMailerHandler may require composer require of the relevant transport package. See the Monolog handler docs for each handler's prerequisites.

File logging

Write every event to a flat file:

Rotating file logging

Rotate logs daily and keep the last seven days. Useful when StreamHandler files grow unbounded:

JSON-structured logging

Emit one JSON object per line — easy to ingest into Loki, ELK, Datadog, etc:

Syslog

Forward events to the host's syslog (handy on managed/cloud platforms that scrape syslog automatically):

SyslogHandler accepts a facility name (string) such as user, daemon, mail, auth, local0–local7. The PHP LOG_* constants are integers that YAML cannot reference; passing the literal string LOG_USER triggers UnexpectedValueException. Stick to the lowercase names above.

PHP error log

Pipe firewall events into the configured PHP error_log — useful in shared hosting or when you don't control filesystem paths:

Email alerts

Send an email when something critical happens. NativeMailerHandler uses PHP's mail() — no extra package required:

For higher-volume alerting via SendGrid (requires ext-curl):

Slack alerts

Post directly to a Slack channel through an Incoming Webhook. Requires ext-curl:

If you prefer the Slack Web API (legacy token-based handler):

Pushover (push notifications)

Send mobile push notifications via Pushover:

IFTTT webhooks

Trigger an IFTTT Maker applet — useful for chaining custom automations (SMS, smart lights, voice assistants, etc.):

IFTTT receives three values: value1 = channel, value2 = level name, value3 = message.

Telegram bot

Send messages to a Telegram channel or chat via a bot token:

Per-handler severity thresholds

Each handler entry has its own level argument, so you can tune verbosity per destination. The pattern below writes every Info-and-above event to file but only escalates Critical events to email:

Handlers that wrap other handlers (e.g. FingersCrossedHandler, BufferHandler, FilterHandler, GroupHandler) take a HandlerInterface as a constructor argument, which the YAML loader cannot construct recursively. To use those, build the logger programmatically with Monolog\Logger and inject it via LoggingFactory::setLogger() before calling Firewall::create().

Combining multiple handlers

You can stack any number of handlers — each entry under logger is independent. A common production setup tees everything to a file, surfaces warnings to syslog, and pages humans via Slack/Pushover only on critical events:

For the full catalogue of available handlers (Telegram, Mandrill, Loggly, Elasticsearch, Sentry via PSR, etc.), see the Monolog handlers reference.

Dynamic Configuration Overrides

For dynamic environments (Docker, multi-site installations), you can override YAML configuration with PHP arrays. Override paths target the source YAML shape (before plugin normalization runs), so the right path depends on how your YAML is written.

Overriding entries written in the plugins: array — the path includes the list index (0, 1, 2, …) in declaration order:

Overriding entries written in the legacy block: / bypass: format — paths still address the plugin by class name (legacy format is normalized after overrides are merged, so this continues to work):

Platform Integration

Drupal

Add to settings.php before the container configuration:

WordPress

Add to wp-config.php after ABSPATH is defined but before wp-settings.php:

Symfony

Add to public/index.php before the kernel boot:

Laravel

Add to public/index.php after the autoloader:

Advanced Examples

Multi-layered Security Configuration

Custom Plugin Implementation

Create a custom plugin to implement specific business logic:

Register the custom plugin in your configuration:

Testing

The firewall includes a comprehensive test suite. Run tests with:

Example Test Case

Legacy format (deprecated)

Earlier versions of this library configured plugins in two separate top-level sections (bypass: and block:), each keyed by the plugin class name. This format is still accepted — Kanopi\Firewall\Utility\PluginConfigNormalizer rewrites it into the plugins: array shape at load time — but it will be removed in a future major release. New configs should use the plugins: array described above.

Side-by-side

Same config in both shapes

You can also mix both formats in the same config during migration — legacy entries are normalized first, then appended to whatever is already in plugins:.

Contributing

We welcome contributions! Please see our Contributing Guide for details.

Development Setup

1. Clone the repository
2. Install dependencies: composer install
3. Run tests: composer test
4. Check code style: composer cs
5. Run static analysis: composer stan

License

This project is licensed under the MIT License. See the LICENSE file for details.

Support

• Documentation: https://github.com/kanopi/firewall/wiki
• Issues: https://github.com/kanopi/firewall/issues
• Discussions: https://github.com/kanopi/firewall/discussions

Credits

Lite Firewall is developed and maintained by Kanopi Studios.

Special thanks to:

• The Symfony team for the excellent HttpFoundation component
• MaxMind for the GeoIP2 databases
• The Monolog team for the flexible logging library
• All our contributors and users