Clamp expires_in at API boundary (#60) #74

Merged
poslop merged 2 commits from issue-60-expiry-clamp into main 2026-09-09 14:26:07 +00:00
Owner

What

The pastes API already clamped expires_in (1min-1yr via store.ValidExpiry, from sweep #33), but the cans API (POST /api/pastes/can) parsed the duration and accepted anything - including 0s, negatives (born-expired cans), and 87600h (10 years, the case reported on #60).

This PR applies the same store.ValidExpiry clamp to the cans create handler: zero/negative and out-of-window durations now return 400 expires_in must be between 1 minute and 1 year.

Tests

TestCreateCanExpiryBounds covers the boundary cases: -1h, -0s, 0s, 1ns, 59s -> 400; 1m, 90s, 8760h -> 201; 8785h, 87600h -> 400.

Closes #60

## What The pastes API already clamped `expires_in` (1min-1yr via `store.ValidExpiry`, from sweep #33), but the **cans API** (`POST /api/pastes/can`) parsed the duration and accepted anything - including `0s`, negatives (born-expired cans), and `87600h` (10 years, the case reported on #60). This PR applies the same `store.ValidExpiry` clamp to the cans create handler: zero/negative and out-of-window durations now return `400 expires_in must be between 1 minute and 1 year`. ## Tests `TestCreateCanExpiryBounds` covers the boundary cases: `-1h`, `-0s`, `0s`, `1ns`, `59s` -> 400; `1m`, `90s`, `8760h` -> 201; `8785h`, `87600h` -> 400. Closes #60
poslop added 2 commits 2026-09-09 14:15:55 +00:00
poslop merged commit 47c9fa6386 into main 2026-09-09 14:26:07 +00:00
Sign in to join this conversation.