The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
PerimeterSubscriber isn't triggered for me on fast404 requests.
The comment in \Drupal\perimeter\EventSubscriber\PerimeterSubscriber::getSubscribedEvents() claims it does, but \Drupal\Core\EventSubscriber\Fast404ExceptionHtmlSubscriber sets a priority of 200, and if an event is set, then the event propagation is stopped and the response is returned early.
Steps to reproduce
Proposed resolution
Set the weight to 300, to be before fast404.
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork perimeter-3506487
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
berdirAh, the comment talks about the fast404 *module*. But Drupal has a built-in fast404 mechanism. I think that has been improved/fixed somewhat recently, so maybe that's the difference?
Comment #4
berdirComment #5
bburgI just came across this doing some testing on my own, discovering that Perimeter doesn't actually work when using fast404. While I like the idea of banning IPs that are probing my site for vulnerabilities, I suppose it's nice that they are still getting the treatment that minimizes demand on my infrastructure.
I did come checking, and I confirm that the core module's BanMiddleware::handle(), which seems to do the checking for banned IPs, does also run before the fast 404 event subscriber, so there should be some added optimization making these modules compatible.
I tested the patch in the merge request locally, and can confirm that the order changed to run Perimeter's event subscriber before Fast 404's.
Is that good enough for RTBC?
Comment #6
groendijk commentedWe're using the patch too. It feels like a bit of a band aid fix for these 2 modules. But I guess this can be released? What do the maintainers say?