Conversation
…ntries When a bulk entry already contained a cip or token_auth key, the proxy overwrote it in place, leaving the proxy's own value at whatever position the entry used instead of a consistent one - http_build_query() keeps an existing key's position when its value is replaced. Unset those keys before assigning the proxy's own so they are always appended last, matching the single-request path, which already unsets token_auth before assigning its own. This is a no-op for entries that carry neither key.
Cover both branches: the per-entry token path (the proxy's token is appended at the end of an entry that already carries a token_auth key) and the top-level token path (an entry's own token_auth key is dropped when no per-entry token is injected).
chippison
approved these changes
Aug 11, 2026
chippison
left a comment
chippison
left a comment
Contributor
There was a problem hiding this comment.
Everything looks good!
Thanks for adding those tests, this closes the gaps 👍
sgiehl
added a commit
that referenced
this pull request
Aug 12, 2026
withProxyTracking() unsets cip before assigning the proxy's own so it is appended last rather than left at an existing key's position (#107). On master the cip half of that unset is unreachable: cip is checked with array_key_exists() in $overrideParams, so any entry carrying a cip key is treated as offending and never reaches the function. Treating an empty or array cip as "no cip" makes it reachable, which is the interaction the unset exists to protect - and nothing covered it: dropping cip from the unset left all 93 tests green while the placeholder visibly moved from the end of the entry to the empty key's position mid-entry. The new test uses an entry whose empty cip is mid-entry, so the position is observable, and asserts the placeholder is appended last. The existing empty-cip test keeps its cip at the end, where both behaviours look identical. Raised in review of #107.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
When a bulk tracking entry already contained a
ciportoken_authkey, the proxy overwrote it in place, leaving the proxy's injected value at whatever position the entry happened to use instead of a consistent one —http_build_query()keeps an existing key's position when its value is replaced. The keys are now unset before the proxy assigns its own, so they are always appended last, matching the single-request path (which already unsetstoken_authbefore assigning its own). This is a no-op for entries that carry neither key. A regression test covers the placement.Checklist