Allow to set options as part of RouteResult #7
Conversation
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 :) |
@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 [
'path' => '/api/projects',
'options' => [
'defaults' => [
'requires_authentication' => false,
],
],
], And with Aura Route setting [
'path' => '/api/projects',
'options' => [
'values' => [
'requires_authentication' => false,
],
],
], @weierophinney how does it work with FastRoute? |
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. |
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. |
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 |
@gabrielsch @bakura10 @danizord 'routes' => [
[
'name' => 'my::route',
'path' => '/myroute',
'middleware' => [
MyMiddleware::class,
],
'allowed_methods' => ['POST'],
'options' => [
'defaults' => [
'my_request_attr' => 'awesome'
],
],
],
], |
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) |
@sandrokeil awesome man, thanks |
Yes, you can access the value via |
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! |
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. |
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:
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.