You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have discussed this feature request with the community.
Describe the background of your feature request
Authorizing based on path components is currently a bit hacky.
If I have an API like /file/<uuid>/delete I need to both match the <uuid> part exactly and then again retrieve it inside of the authorizer by extracting it out of .Request.URL.Path. This kind of double matching is in my opinion error-prone, and retrieving path segments from the full path via regular expressions or numeric indexing is not very readable, especially if the template is defined separately from the rule.
Describe your idea
I propose an additional kind of matcher, which would always be named and equivalent to the <*> glob (though to be useful #1037 needs to be implemented in some capacity).
This matcher would be trivially convertable to regexp, where named capturing shouldn't be an issue (unlike with the current glob library).
Compare
rules:
- id: rule:1match:
url: http://hosty.mchostface/files/<*>/deleteforward_to:
host: server:8080methods:
- ALLexecute:
- authorizer: openfga_check # remote authorizer config:
# Note: I originally wanted to do this with values, but apparently they cannot template? They should be able to :vpayload: | { "user": {{ .Subject.ID | quote }}, "relation": "can_delete", "object": "file:{{ index (splitList "/" .Request.URL.Path) 2 }}" }
Preflight checklist
Describe the background of your feature request
Authorizing based on path components is currently a bit hacky.
If I have an API like
/file/<uuid>/delete
I need to both match the<uuid>
part exactly and then again retrieve it inside of the authorizer by extracting it out of.Request.URL.Path
. This kind of double matching is in my opinion error-prone, and retrieving path segments from the full path via regular expressions or numeric indexing is not very readable, especially if the template is defined separately from the rule.Describe your idea
I propose an additional kind of matcher, which would always be named and equivalent to the
<*>
glob (though to be useful #1037 needs to be implemented in some capacity).This matcher would be trivially convertable to regexp, where named capturing shouldn't be an issue (unlike with the current glob library).
Compare
and
Are there any workarounds or alternatives?
See the first example above
Version
dev (cda0a84)
Additional Context
Originally suggested on Discord here: https://discord.com/channels/1100447190796742698/1174322443859538000/1174322443859538000
The text was updated successfully, but these errors were encountered: