[Security] json login listener: ensure a json response is sent on bad request #22585
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stof
requested changes
Apr 30, 2017
| @@ -180,4 +180,11 @@ private function onFailure(Request $request, AuthenticationException $failed) | |||
|
|
|||
| return $response; | |||
| } | |||
|
|
|||
| private function throwBadRequestHttpException(Request $request, $message, \Exception $previous = null) | |||
There was a problem hiding this comment.
I would not throw inside the method, as it means you have to inspect this method to know that the flow stops in the main method. Instead, create a method returning the exception, and keep throwing it in the main method
There was a problem hiding this comment.
Indeed, makes sense. Thank you.
EDIT: Eventually it looks even better to simply catch, set format and re-throw from the main method.
stof
approved these changes
Apr 30, 2017
|
Thank you @ogizanagi. |
stof
added a commit
that referenced
this pull request
Apr 30, 2017
…sent on bad request (ogizanagi)
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] json login listener: ensure a json response is sent on bad request
| Q | A
| ------------- | ---
| Branch? | master (3.3)
| Bug fix? | yesish
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
I would have simply recommended to set the proper format when declaring the route:
```yml
# routing.yml
api_login:
path: /login
defaults: { _format: json }
```
but, since #22477 has been merged, and considering #22477 (comment):
> my point above regarding checking the content type is so that one could use form_login and json_login in parallel on the same routes and within the same firewall
we may consider setting the request format to json when throwing the `BadRequestHttpException`, so used conjointly with the TwigBundle, the exception is rendered using the `exception.json.twig` template.
ping @lsmith77
(An alternative would be to check the Accept header to set the request format to json if it's the preferred one instead of doing it each time we throw the exception. But Symfony never used such content negotiation AFAIK, and I think it's safe enough to assume someone sending json is expecting json as ouput for exceptions.)
Commits
-------
4427cf9 [Security] json login listener: ensure a json response is sent on bad request
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I would have simply recommended to set the proper format when declaring the route:
but, since #22477 has been merged, and considering #22477 (comment):
we may consider setting the request format to json when throwing the
BadRequestHttpException, so used conjointly with the TwigBundle, the exception is rendered using theexception.json.twigtemplate.ping @lsmith77
(An alternative would be to check the Accept header to set the request format to json if it's the preferred one instead of doing it each time we throw the exception. But Symfony never used such content negotiation AFAIK, and I think it's safe enough to assume someone sending json is expecting json as ouput for exceptions.)