AccessDeniedException is converted to HTTP 302 even when request format is JSON

[Jontsa]

Description

When accessing a secured area using AJAX + JSON while not logged in, the ExceptionListener in Symfony Security component may convert AccessDeniedException to a HTTP 302 redirect to login page. The javascript can not really do anything with this since it is expecting JSON or HTTP error code.

Any other exception would be converted to JSON and passed back to browser with correct HTTP status code. But in this case, you need to create your own event listener to convert this exception in to JSON. This is the same issue as reported here: https://stackoverflow.com/questions/33240554/symfony2-security-annotation-turn-off-redirect-when-not-logged-in

See: Symfony\Component\Security\Http\Firewall\ExceptionListener::handleAccessDeniedException()

How to reproduce

• Setup controller that throws AccessDeniedException
• Setup controller that mocks a login page
• Configure route to login page in security.yaml form_login > login_path
• Try to access the first controller using AJAX + JSON
• You expect a HTTP 403 error but instead you get HTTP 200 with login page contents

If needed, I can provide an example project in Github.

[xabbuh]

I think a small example project would indeed be very helpful for anyone wanting to look into it.

[Jontsa]

Here is a simple project where you have two end points for ajax. Both throw exception but AccessDeniedException does not trigger HTTP error.

• git clone git@github.com:Jontsa/security-http-example.git
• cd security-http-example/
• composer install && bin/console server:start

[nicolas-grekas]

@Jontsa would you be able to debug why?

[dimabory]

@nicolas-grekas, @xabbuh Do you guys aware of this return statement? Looks like this produces an issue not only with redirecting but also with custom access denied handler (see #28229).

Btw, I think we can safely remove it.

[dimabory]

@Jontsa Btw, you can just make form_login: false to prevent redirection https://github.com/Jontsa/security-http-example/blob/afee744e4b46e54275bfeee24adf66630024efd2/config/packages/security.yaml#L13

[curry684]

I reviewed this and I don't think there's an actual issue here. The XHR request itself contains no usable indication that the redirect response is not valid, so Symfony is correct in following up with the redirect based on its configuration. And as @dimabory said you can/should just change that config line which fixes your issue correctly.

The return statement may be a real issue but it has its own dedicated issue already.

Status: reviewed