8000 [HttpKernel] Support querystring in action arguments · Issue #19655 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[HttpKernel] Support querystring in action arguments #19655

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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
linaori opened this issue Aug 18, 2016 · 11 comments
Closed

[HttpKernel] Support querystring in action arguments #19655

linaori opened this issue Aug 18, 2016 · 11 comments
Labels
Feature HttpKernel

Comments

@linaori
Copy link
Contributor
linaori commented Aug 18, 2016

One feature I'm often missing, is the ability to fetch query parameters directly from the method arguments. With the refactoring I've made it easier to add functionality, I was thinking to use this if the feature would be decided.

Current scenario

class FooController
{
    /**
      * Calling "/foo?bar=baz"
      * @Route("/foo")
      */
    public function fooAction(Request $request)
    {
        return new Response(sprintf('Your query was %s.', $request->query->get('bar')));
    }
}

Proposed scenario

class FooController
{
    /**
      * Calling "/foo?bar=baz"
      * @Route("/foo")
      */
    public function fooAction(Request $request, $bar)
    {
        return new Response(sprintf('Your query was %s.', $bar'));
    }
}

This should also support arrays and optional values for example:

class FooController
{
    /**
      * Calling "/foo?bar[]=baz&bar[]=hello-world"
      * @Route("/foo")
      */
    public function fooAction(Request $request, array $bar = [])
    {
        // ...
    }
}

Would this be something I can add to the core? If not I can add it to my own bundle for people that do need it.
@HeahDude
Copy link
Contributor

There is already http://symfony.com/doc/master/bundles/FOSRestBundle/annotations-reference.html, wouldn't an argument value resolver mess with it?

@linaori
Copy link
Contributor Author
linaori commented Aug 18, 2016

I'm not entirely sure how this implementation works, but I doubt it. The argument value resolver will simply check if the request parameter exists (just like the attribute variant) and yield it if possible.

@linaori
Copy link
Contributor Author
linaori commented Aug 18, 2016

The other solution would be to add the parameters in Symfony elsewhere, meaning they end up in the attributes. This would make it possible to create a parameter converter for ?post=1 where the 1 gets converted into a Post object.

@fabpot
Copy link
Member
fabpot commented Aug 18, 2016

It has been rejected in the past. Being able to get the value of routing parameters is ok (/:foo), but being able to get anything passed by the user is a no-go in terms of security.

@linaori
Copy link
Contributor Author
linaori commented Aug 18, 2016 •
edited
Loading

But wouldn't it be the exact same thing as reading the request query manually? It would merely be a shortcut. I could also add bogus info there or in the route parameters, wouldn't make a difference as far as I can tell. I could even make a parameter converter that already does this so I fail to see which security issues this would raise.

@ro0NL
Copy link
Contributor
ro0NL commented Aug 18, 2016 •
edited
Loading

@iltar you're right, it's the same when reading manually. However, that's the risk in terms of security, we just should not advertise with "add a method argument, and it's automagically populated by the user" (whereas route arguments are controlled by the developer).

Eventually we create a backdoor entrance; the risk of writing "bad" code that is. (Consider the no. of projects this is gonna affect.)

@linaori
Copy link
Contributor Author
linaori commented Aug 19, 2016

In that case, would it be an idea to white-list query string parameters in the route config?

@ro0NL
Copy link
Contributor
ro0NL commented Aug 19, 2016 •
edited
Loading

Could work. Not sure how intuitive that is, not everybody uses annotations/comments to clarify.

Personally i was thinking more along the lines of;
public function someAction(Request $request, Param $bar)

Think $bar->isQuery(), $bar->isGiven(), etc.

But yes, if we go this way, we need a whitelist. Period :)

edit: i like the idea, because it allows for less boilerplate controller code (validating the request), ie im also waiting for stuff like #19296
edit2: however, if we could do getOrThrow404 quickly some other way, this is maybe not really needed

@Koc
Copy link
Contributor
Koc commented Aug 21, 2016

Ref #3254

@linaori
Copy link
Contributor Author
linaori commented Jun 21, 2017

Closed at it will most likely not be fixed

@linaori linaori closed this as completed Jun 21, 2017
@bohdanyurov-gl
Copy link

@fabpot I am still curious about whitelisting GET query parameters. Shouldn't it resolve your security concerns?

@chalasr chalasr mentioned this issue Sep 19, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature HttpKernel
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@fabpot @javiereguiluz @Koc @ro0NL @linaori @HeahDude @bohdanyurov-gl
0