fix: harden vary dimensions with path safety and bigint regression test#436
Merged
fix: harden vary dimensions with path safety and bigint regression test#436
Conversation
…gression test Address review feedback from #435: 1. Path safety validation in composeDataName(): Vary values that contain path separators (/ or \) or relative path components (. or ..) are now rejected with clear error messages. This prevents vary values from creating data outside the expected directory structure, hardening against future use cases where vary values may come from untrusted sources. 2. Explicit bigint regression test: Added a test that simulates the DataCache's strict number-keyed Map.get() behavior to verify that CEL int values (which may be bigint) are correctly converted to number before cache lookup. This covers both the 3-arg and 4-arg (with vary) forms of data.version(), preventing regression of the fix from #435. Test coverage: - 4 new unit tests for path safety (forward slash, backslash, .., .) - 1 new regression test for bigint-to-number conversion - All 1867 tests pass Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Review Summary
Approved - This PR cleanly addresses the review feedback from #435.
Changes Verified:
-
Path safety validation in
composeDataName()- Correctly rejects vary values containing:- Path separators (
/,\) - Relative path components (
.,..) - Clear, actionable error messages
- Path separators (
-
Bigint regression test - Validates that CEL
intvalues (bigint) work correctly withdata.version()cache lookup
Checklist:
- ✓ TypeScript strict mode, no
anytypes - ✓ Named exports (no default exports)
- ✓ AGPLv3 license headers present
- ✓ Unit tests next to source files
- ✓
@std/assertassertions used - ✓ Security: Path traversal prevention is a good hardening measure
DDD Review:
The composeDataName function correctly implements domain validation as a pure function, enforcing invariants on valid data names in the domain layer.
Suggestions (non-blocking):
The regex /[\/\\]/ could be simplified to /[/\\]/ (forward slashes don't need escaping in character classes), but this is purely stylistic - the current version is correct.
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.
Summary
Addresses review feedback from #435 (vary dimensions for environment-isolated
data storage). Two non-blocking suggestions were made during review — this PR
implements both.
Changes
1. Path safety validation in
composeDataName()composeDataName()now rejects vary values containing path-unsafe characters:/,\) — prevents values like../../etcfromcreating data outside the expected directory
.,..) — prevents directory traversalCurrent usage is safe since vary values come from controlled workflow inputs,
but this hardens the function against future use cases where values may come
from less trusted sources.
Error messages are clear and actionable:
2. Explicit bigint regression test for
data.version()Added a test that simulates the real
DataCachebehavior — aMapwithnumberkeys — to verify that CELintvalues (which JavaScript representsas
bigint) are correctly converted toNumber()before cache lookup.This test would have caught the latent bug fixed in #435 where
Map.get(1n)silently returnedundefinedwhen the key was1(number),causing
data.version()to return null.The test covers both:
data.version("scanner", "result", 1)data.version("scanner", "result", ["prod"], 1)Test coverage
Verification
deno check— passdeno lint— passdeno fmt— passdeno run test— 1867 passed, 0 faileddeno run compile— pass🤖 Generated with Claude Code
Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com