guilhermevillote commented on issue #12349:
URL: https://github.com/apache/apisix/issues/12349#issuecomment-2988301341
Yes, I believe it is possible to save the original route configuration
during the rewrite phase (when the consumer config has not yet been merged) and
store it in the ctx for use in the access phase ā that seems technically
feasible.
However, I would like to confirm if this is indeed the best approach for
scenarios where we need access to both the route-level and consumer-level
plugin configurations separately.
Also, Iād like to correct a mistake in my previous message:
The matched route does contain the plugin configuration (I overlooked this
before). So, this part of my previous statement was incorrect.
Still, when a plugin is defined on both the route and the consumer, the
plugin configuration shown in the matched route seems to be the merged version,
and I can no longer see the original route-level configuration.
For example:
```json
"plugins": {
"proxy-rewrite": {
"regex_uri": ["^/admin/test/(.*)", "/apisix/admin/$1"]
},
"key-auth": {
"_skip_rewrite_in_consumer": true,
"key": "auth-one"
},
"acl": {
"groups": ["devops"]
}
}
```
Here, proxy-rewrite appears as defined on the route (it is not set on the
consumer), but key-auth and acl reflect only the consumer-side config, even
though I defined them on both.
So, I have three main questions:
1) Is it possible to access both the route and consumer configurations
separately within the plugin logic? Right now, it seems like only the merged
result is available, making it difficult to distinguish what was defined where.
2) How does the merge strategy work internally? Is there any way to support
a hierarchical merge, where the route-level config serves as the base, and the
consumer config only overrides the specific conflicting fields ā instead of
completely replacing the route config?
3) Is saving the route config during the rewrite phase into ctx (before the
consumer merge) the recommended solution to preserve the original route
configuration, or is there a better or more idiomatic way to handle this in
custom plugins?
Thanks again for your help!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]