fix: validate dimensions and fit mode on encrypted URLs (closes #62)

Conversation 0 Commits 2 Files Changed 8

+379 -24

2 Commits

Author	SHA1	Message	Date
sneak	a663669286	fix: validate dimensions and fit mode on encrypted URLs (closes #62 ) check / check (push) Successful in 2m30s Details The encrypted /v1/e/ route built its image request straight from the decrypted payload, so a token could request an over-limit dimension (reaching libvips and exhausting memory) or an unknown fit mode (surfacing as a 500 from the processor). The token generator discarded every strconv.Atoi error, silently turning non-numeric width, height, quality, or ttl into 0 and applying no upper bound on dimensions. Add a shared ValidateImageRequest in internal/imgcache enforcing the MaxDimension bound and ValidateFitMode, and apply it on both the plain image route and the encrypted route so both reject an over-limit size or an unrecognized fit mode with 400. The generator now parses each numeric field explicitly and returns 400 naming the field for non-numeric or out-of-range input, with width and height bounds-checked so an unusable token cannot be minted. Model: opus-4-8	2026-09-21 20:17:08 +00:00
sneak	6d380fbf98	test: cover encrypted-URL and generator validation gaps (#62 ) Failing tests for the missing validation on the encrypted-URL path and the token generator: an encrypted token carrying an over-limit dimension or an unrecognized fit mode must be rejected with 400, and POST /generate with a non-numeric or over-limit width must return 400 rather than minting a token. Also covers the shared imgcache validator directly. Model: opus-4-8	2026-09-21 20:17:08 +00:00

Author

SHA1

Message

Date

sneak

a663669286

fix: validate dimensions and fit mode on encrypted URLs (closes #62 )

check / check (push) Successful in 2m30s

Details

The encrypted /v1/e/ route built its image request straight from the
decrypted payload, so a token could request an over-limit dimension
(reaching libvips and exhausting memory) or an unknown fit mode
(surfacing as a 500 from the processor). The token generator discarded
every strconv.Atoi error, silently turning non-numeric width, height,
quality, or ttl into 0 and applying no upper bound on dimensions.

Add a shared ValidateImageRequest in internal/imgcache enforcing the
MaxDimension bound and ValidateFitMode, and apply it on both the plain
image route and the encrypted route so both reject an over-limit size or
an unrecognized fit mode with 400. The generator now parses each numeric
field explicitly and returns 400 naming the field for non-numeric or
out-of-range input, with width and height bounds-checked so an unusable
token cannot be minted.

Model: opus-4-8

2026-09-21 20:17:08 +00:00

sneak

6d380fbf98

test: cover encrypted-URL and generator validation gaps (#62 )

Failing tests for the missing validation on the encrypted-URL path and
the token generator: an encrypted token carrying an over-limit dimension
or an unrecognized fit mode must be rejected with 400, and POST /generate
with a non-numeric or over-limit width must return 400 rather than
minting a token. Also covers the shared imgcache validator directly.

Model: opus-4-8

2026-09-21 20:17:08 +00:00

fix: validate dimensions and fit mode on encrypted URLs (closes #62) #126