Skip to content

Authentication exceptions logged before having the chance to get handled #27440

Closed
@spantaleev

Description

@spantaleev

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 an AccessDeniedException 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions