ben.stull
118e925580
The email-step Send button disabled on any running cooldown, so a merchant who mistyped their address was locked out of sending to the corrected one for the rest of the 60s window — a guard the server never had: request_code enforces the cooldown per address (SD-0001 INV-3 -> PUC-2c). Track which address the running cooldown belongs to (cooldownFor) and gate the email-step button through cooldownAppliesTo(), which blocks only while the countdown runs AND the input normalizes (strip+lowercase, mirroring normalize_email / INV-2) to that address. Same address still shows the honest 'Resend in Ns'; any other address sends immediately. The code-step resend is unchanged. Verified in the live UI (wrong address -> Wrong address? -> corrected address sends at once). package-lock.json: sync recorded version with package.json (0.4.0). Closes #20 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
25 lines
959 B
TypeScript
25 lines
959 B
TypeScript
import { describe, expect, it } from "vitest";
|
|
import { cooldownAppliesTo } from "./cooldown";
|
|
|
|
describe("resend cooldown keying (SD-0001 §5.2, INV-3; bug #20)", () => {
|
|
it("no cooldown running -> send not blocked", () => {
|
|
expect(cooldownAppliesTo("a@example.com", null, 0)).toBe(false);
|
|
});
|
|
|
|
it("cooldown running for the same address -> blocked", () => {
|
|
expect(cooldownAppliesTo("a@example.com", "a@example.com", 31)).toBe(true);
|
|
});
|
|
|
|
it("same address modulo case/whitespace -> still blocked", () => {
|
|
expect(cooldownAppliesTo(" A@Example.COM ", "a@example.com", 31)).toBe(true);
|
|
});
|
|
|
|
it("cooldown running but the input is a different address -> not blocked", () => {
|
|
expect(cooldownAppliesTo("right@example.com", "wrong@example.com", 31)).toBe(false);
|
|
});
|
|
|
|
it("cooldown expired -> not blocked even for the same address", () => {
|
|
expect(cooldownAppliesTo("a@example.com", "a@example.com", 0)).toBe(false);
|
|
});
|
|
});
|