Description
Symfony version(s) affected: 4.1.0
Description
Seems like ever since #25366, authentication exceptions are first logged, and then handled gracefully (redirecting to a login entrypoint).
If an unauthenticated user hits a route they cannot access (e.g. a homepage route with this firewall rule - { path: ^/, role: ROLE_ADMIN }
), what currently happens is:
-
step 1:
Symfony\Component\Security\Http\Firewall\AccessListener
rightfully throws anAccessDeniedException
exception -
step 2: because of its new and high priority level (of
2048
since [HttpKernel] Decouple exception logging from rendering #25366),Symfony\Component\HttpKernel\EventListener\ExceptionListener
decides to log this exception:Uncaught PHP Exception AccessDeniedException ...
. Logging such a CRITICAL error has the bad side-effect of causing Monolog to send me an email. -
step 3: because of its (now-comparatively-low) priority level of
1
,Symfony\Component\Security\Http\Firewall\ExceptionListener
gets triggered. It converts the exception to a (redirect)Response
(to the login page), and the website appears to work. However, it's way too late already, as "step 2" (above) already logged the error and sent me an exception email.
Possible Solution
Symfony\Component\Security\Http\Firewall\ExceptionListener
can be executed with a higher priority than Symfony\Component\HttpKernel\EventListener\ExceptionListener
, so that graceful handling of authentication exceptions can happen before logging.
Changing Symfony\Component\Security\Http\Firewall\ExceptionListener
, so that the KernelEvents::EXCEPTION
priority is higher (from 1
to 2049
) works around the problem.