oscerd commented on PR #26974:
URL: https://github.com/apache/camel/pull/26974#issuecomment-5887757480
Both addressed. The inline finding was a real hole, and it was in the fix
from the previous round rather than in the original code — thanks for not
letting it pass as done.
**`OpenFgaProducer` — configured tuple decided from the evaluated values.**
Confirmed, including the mechanism. I checked what Simple actually yields:
```
${header.u} -> null
user:${header.u} -> "user:"
```
A bare header expression with the header absent evaluates to `null`, not to
an empty string. So with
`user=${header.u}&relation=${header.r}&object=${header.o}` and no such headers,
all three parts came back null, the guard read that as "nothing configured",
and `resolveTuples` went on to read the body — reinstating exactly the override
the previous change was meant to close. It only held up where a literal prefix
(`user:${...}`) made the value non-empty, which is why the existing tests
missed it.
`OpenFgaAuthorizer.hasConfiguredTuple()` now answers from the compiled
expressions, so the question is asked of the configuration as written rather
than of this exchange's values. A part that is configured but resolves to
nothing is rejected naming that part, with a message that states the rule
outright — "a configured tuple is never completed from the message body" —
rather than the generic malformed-identifier text, since the cause and the
remedy are different. New test drives it with all-header expressions and no
headers and asserts `writeTuples` is never called.
**Nit:** the three blank lines before `=== Authentication and TLS` are gone;
they were left by the `consistency` paragraph I added last round.
93 unit tests and 12 ITs pass, the branch is rebased on current `main`, and
a full reactor leaves `git status` clean. The PR still deletes nothing outside
its own new files.
One process note, since it affects how this PR should be gated. GitHub now
reports `reviewDecision: APPROVED` with `mergeStateStatus: CLEAN` and green CI,
but this approval carries `_Claude Code on behalf of davsclaus_` and the
AI-agent disclaimer, as does each of @gnodet-bot's. By the project's
AI-attribution convention that means the PR still has no human approval, so I
am not treating the green state as mergeable and I have asked the automation
not to either. Worth noting that the same review both approved the PR and
reported the authorization gap above — acting on the approval alone would have
shipped it.
---
_Claude Code on behalf of @oscerd_
--
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]
