mikyll commented on issue #13140:
URL: https://github.com/apache/apisix/issues/13140#issuecomment-4177540088
@Baoyuantop
## Personal Use Case
My specific use case is somewhat similar to the one described in #13132: we
have a route that points to an external provider, which is configured to append
an apikey in the query string via `proxy-rewrite` plugin (e.g.
`/api/users/:user_id/` -> `/api/users/:user_id/?apikey=foobar123`).
I'd like to fetch the API key with another plugin (or via
`serverless-pre-function`), inject it in a context variable, e.g.
`ctx.var.apikey` and then retrieve it in `proxy-rewrite`.
Pseudo-code example:
```yaml
uri: /api/users/:user_id
plugins:
serverless-pre-function:
phase: rewrite
functions:
- |
return function(_, ctx)
ctx.var.myapikey = fetch_secrets(ctx.var, true) -- Or some other
logic to fetch the secret
end
proxy-rewrite:
host: external-host
regex_uri:
- ^/api/users/(.*)$
- /v2/api/users/$1/?apikey=$myapikey
```
Moreover, since the route also uses path parameters (`user_id` -> `$1`), we
cannot use `.uri` and must use `.regex_uri`.
## Considerations
I understand this would be a _free_ "positive side-effect" of the feature,
and not the main intended behaviour 🙂
However, the main point I'd like to address is that, to me, it just makes
sense because `.uri` already supports it, and `.regex_uri` should be a _an
extension_ to what `.uri` can do 👀
That's also why I was wondering if that could introduce any unknown/negative
side-effect, because maybe it was implemented this way for a specific design
choice 🙂
I can propose a PR if you think this feature would be useful
--
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]
