Fix JSONPath ambiguity check in ALLOW mode#323
Open
Breus wants to merge 2 commits into
Open
Conversation
|
Note These results are affected by shared workloads on GitHub runners. Use the results only to detect possible regressions, but always rerun on a more stable machine before drawing conclusions! Benchmark resultsBaselineBenchmark
Full results — BaselineBenchmark
InstanceCreationBenchmarkNo significant changes (all within 3.0%). Full results — InstanceCreationBenchmark
JsonMaskerBenchmark
Full results — JsonMaskerBenchmark
LargeKeySetInstanceCreationBenchmarkNo significant changes (all within 3.0%). Full results — LargeKeySetInstanceCreationBenchmark
StreamTypeBenchmark
Full results — StreamTypeBenchmark
ValueMaskerBenchmark
Full results — ValueMaskerBenchmark
Raw output (PR @ e6e91fd)Raw output (master @ ea41a65) |
In ALLOW mode, JSONPaths added via maskJsonPaths(path, KeyMaskingConfig) were only stored in targetKeyConfigs and not in targetJsonPaths. Since build() only checked targetJsonPaths for ambiguity, these paths were never validated — neither against each other nor against allowJsonPaths entries. The fix merges JSONPath entries from targetKeyConfigs into the ambiguity check set using tryParse (which skips plain key names). Also adds Javadoc to targetKeyConfigs clarifying that it contains both plain key names and JSONPath strings. Fixes #318
f4674e1 to
966553d
Compare
ac2b8c5 to
de595ab
Compare
…tKeyConfigs Replace the tryParse-based approach with a dedicated customConfigJsonPaths set that tracks JSONPaths added via maskJsonPaths(path, config). This avoids reparsing strings at build time and is consistent with the existing split between targetKeys and targetJsonPaths. Also adds positive test cases to verify that non-ambiguous ALLOW mode combinations and plain key configs are not affected.
de595ab to
e6e91fd
Compare
|
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
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.



Problem
In ALLOW mode, JSONPaths added via
maskJsonPaths(path, KeyMaskingConfig)are stored only intargetKeyConfigs(not intargetJsonPaths). Sincebuild()only calledcheckAmbiguity(targetJsonPaths), these paths were never validated for ambiguity — neither against each other, nor againstallowJsonPathsentries.For example, this config should throw but didn't:
Fix
JsonMaskingConfig.build(): Merge JSONPath entries fromtargetKeyConfigs(usingtryParseto skip plain key names) into the ambiguity check set before callingcheckAmbiguity.targetKeyConfigs(both outer class and builder fields) clarifying that it contains both plain key names and JSONPath strings.JsonMaskingConfigTest.invalidBuilders():allowJsonPathsandmaskJsonPaths(path, config)maskJsonPaths(path, config)calls in ALLOW modeFixes #318