Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.6k
[HttpFoundation] change precedence of parameters in Request::get#16076
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| * | ||
| * Avoid using this method in controllers: | ||
| * | ||
| * * slow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
this is not relevant anymore with the removal ofdeep and also since the refactoring in#12369
An alternative would be to deprecate |
@Tobion I think this PR is fine without introducing another method. 👍 |
Thank you@Tobion. |
…quest::get (Tobion)This PR was merged into the 3.0-dev branch.Discussion----------[HttpFoundation] change precedence of parameters in Request::get| Q | A| ------------- | ---| Bug fix? | no| New feature? | no| BC breaks? | yes| Deprecations? | no| Tests pass? | yes| Fixed tickets | -| License | MIT| Doc PR | -Allowing the request attributes to be overwritten via GET parameters is risky and made#8966 even worse.It is even more risky because it skips the requirements checks as configured in routing. So people that set requirements for routing placeholders like `\d+` or `html|json` can be sure it is validated when using the routing variables. But if developers use `$request->get()` to retrieve them, anybody from outside can set any value for those.Commits-------e8d6764 [HttpFoundation] change precedence of parameters in Request::get
Allowing the request attributes to be overwritten via GET parameters is risky and made#8966 even worse.
It is even more risky because it skips the requirements checks as configured in routing. So people that set requirements for routing placeholders like
\d+orhtml|jsoncan be sure it is validated when using the routing variables. But if developers use$request->get()to retrieve them, anybody from outside can set any value for those.