Baoyuantop commented on issue #13440:
URL: https://github.com/apache/apisix/issues/13440#issuecomment-4551721771
From the code path, `response-rewrite` should not be the place where the
JSON structure is changed. It only resolves `$http_x_userinfo` and copies that
request header value to the response header.
The `X-Userinfo` header is set earlier by the `openid-connect` plugin. The
plugin gets `userinfo` / `response.user` from `lua-resty-openidc`, JSON-encodes
it, base64-encodes it, and then sets it as the `X-Userinfo` request header. To
verify what APISIX receives directly from the IDP userinfo endpoint, please
temporarily set the APISIX error log level to `debug` in a test environment,
reproduce the request once, and check `error.log` for the `userinfo response:
...` line. That log is emitted after `lua-resty-openidc` calls the userinfo
endpoint and before APISIX re-encodes the value into `X-Userinfo`.
Please be careful because userinfo may contain sensitive user data. I would
not recommend enabling debug logging for a long time in production, and please
redact sensitive fields before sharing logs.
Could you please provide the following details?
1. The full `openid-connect` plugin configuration, with secrets/tokens
redacted.
2. Whether this request uses authorization code flow, bearer token
introspection, or JWKS validation.
3. The `userinfo response: ...` line from debug logs.
4. The base64-decoded `X-Userinfo` value for the same request.
If the debug log already shows `roles` as `{}`, APISIX is receiving it in
that form from the IDP. If the debug log shows `roles` as `[]` but the decoded
`X-Userinfo` shows `{}`, then we can continue investigating JSON decode/encode
preservation in APISIX / lua-resty-openidc.
--
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]
