Skip to content
This repository has been archived by the owner on Jan 21, 2020. It is now read-only.

Allow to set options as part of RouteResult #7

Closed
wants to merge 1 commit into from

Conversation

bakura10
Copy link

@bakura10 bakura10 commented Feb 7, 2016

Hi,

I have a use case where I need some routes to be "unauthenticated". Unfortunately, they have the same base path so I cannot easily segregate them using different middlewares.

I first thought of simply creating my own config mechanism with a "unauthenticated_routes" and do the check, but I feel that the "options" parameter bag associated with route could also be used for any additional metadata.

Also, now that we have separated dispatched and routing middleware, it makes this trivial to use. For instance, here is a route definition:

return [
    'routes' => [
          [
              'path' => '/api/projects',
              'options' => [
                  'requires_authentication' => false
              ]
          ]
    ]
]

The requires_authentication is a custom option that will now be available as part of the RouteResult. It therefore makes trivial for a AuthenticationMiddleware to check that, and if this is set to true, does not require authentication.

I'll update other packages as a consequence of this change.

PS: I can see that the "RouteResult" is not tested as part of this package. I didn't add test as a consequence but it may be a good idea to unit-test this class, especially as it contains quite a bit of logic.

@bakura10
Copy link
Author

bakura10 commented Feb 7, 2016

The only possible drawback is that an "attribute" here for user-land consumption may actually be used or prohibited by the underlying router implementation, as all options are transferred.

Maybe we could instead introduce a separate "metadata" or "attributes", in addition to the "options" parameters. This would allow to keep clear the distinction between routing options and userland metadata.

Also ping @danizord :)

@danizord
Copy link

@bakura10 we already have RouteResult#getMatchedParams() that can be used for that.

I'm not sure how it works with FastRoute, but with Zend Router you can achieve that by setting defaults key under options, like that:

[
    'path' => '/api/projects',
    'options' => [
        'defaults' => [
            'requires_authentication' => false,
        ],
    ],
],

And with Aura Route setting values key:

[
    'path' => '/api/projects',
    'options' => [
        'values' => [
            'requires_authentication' => false,
        ],
    ],
],

@weierophinney how does it work with FastRoute?

@bakura10
Copy link
Author

Does this work? getMatchedParams does not return any of the option actually :(.

@weierophinney
Copy link
Member

Does this work? getMatchedParams does not return any of the option actually :(.

What router are you using? Can you provide a sample of configuration? I've used both FastRoute and the zend-mvc router, and matched parameters were injected into the route result and request attributes just fine; for zend-mvc, defaults were also present where the parameter had no corresponding segment of no value was present for the segment. My suspicion is misconfiguration at this point.

@danizord
Copy link

Does this work? getMatchedParams does not return any of the option actually :(.

It does not return route options, but route parameters (those matched by the router). The point is that you can supply default parameters via config like I did in my last comment.

@gabrielsch
Copy link

It seems like FastRouter does not support route options/params just like AuraRouter and ZendRouter 😞

@bakura10 I'm getting the same problem

ping @weierophinney / @danizord

@sandrokeil
Copy link

@gabrielsch @bakura10 @danizord
Fast route (tested with the new version 1.1.1) supports now default options like the Aura Router. Here is an example

'routes' => [
        [
            'name' => 'my::route',
            'path' => '/myroute',
            'middleware' => [
                MyMiddleware::class,
            ],
            'allowed_methods' => ['POST'],
            'options' => [
                'defaults' => [
                    'my_request_attr' => 'awesome'
                ],
            ],
        ],
    ],

@danizord
Copy link

danizord commented May 5, 2016

Thanks @sandrokeil! Does Expressive add these default options as request attributes? If yes, I'll refactor my authorization middleware this week to use it (currently I'm parsing the router config, meh)

@gabrielsch
Copy link

@sandrokeil awesome man, thanks

@sandrokeil
Copy link

Does Expressive add these default options as request attributes?

Yes, you can access the value via $request->getAttribute('my_request_attr');.

@michaelmoussa
Copy link
Contributor

This conversation seemed to stop abruptly. Is this PR still applicable, or can this be achieved by pulling from request attributes? Please let me know so that I can either close or see about getting this merged.

Thanks!

@michaelmoussa
Copy link
Contributor

I checked the answer in this comment using version 1.0.3 of the Zend Expressive Skeleton using all three routers.

All appears to function in such a way to satisfy the original inquiry, so I'm closing this issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants