Skip to content

feat(sdk): a typed decision, and characteristics for who the caller is - #28

Merged
cport1 merged 1 commit into
mainfrom
feat/typed-decision
Aug 22, 2026
Merged

feat(sdk): a typed decision, and characteristics for who the caller is#28
cport1 merged 1 commit into
mainfrom
feat/typed-decision

Conversation

@cport1

@cport1 cport1 commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

Closes #730 and #731. First of the milestone-26 batch, and the foundational one — #734 (testing utilities) and the any burndown both build on it.

#730 — the decision

protect() returned { allowed, detection }, and all three adapters typed the value they hand to onBlocked as any. Integrating meant destructuring a blob and string-matching to find out which rule fired. Three things the SDK already knew had nowhere to go:

Which rules ran. The engine collapsed to one deciding rule plus a violations array. A filter() rule that never ran for want of IP enrichment and one that ran and passed both reported ALLOW — indistinguishable, and the first reads as "checked, and this IP is fine". Every rule now appears in results[]:

state Meaning
RUN Evaluated, conclusion counts
DRY_RUN Evaluated, conclusion recorded but not enforced
NOT_RUN Could not evaluate — a needed signal was absent
CACHED Not evaluated; a prior decision was reused

A dry-run rule that matched reports conclusion: 'DENY' with state: 'DRY_RUN'. Reading its action verbatim would show it as ALLOW, which is the opposite of what the operator turned it on to see.

"Challenge this one." We ship a proof-of-work captcha in @webdecoy/client and the decision type could not express a challenge, so it was reachable only by wiring it up by hand. CHALLENGE is now a conclusion, produced when the server says challenge and the score cleared the threshold.

A stable id. 'rule_' + Date.now() is not unique under concurrency and correlates with nothing. Now a random dec_…, also stamped on detection.detection_id so the two join. Random rather than sequential because ids leave the process, and a counter leaks request volume to anyone who sees two.

Plus deniedBy('tripwire'), and ERROR as a distinct conclusion from DENY — both serve the request, but only one of them means "we never decided".

Compatibility. allowed is unchanged, including failing open on ERROR. onBlocked gets the decision as a trailing argument, so existing handlers are untouched; detection is now typed SDKDetectionResponse instead of any.

One trap worth noting: protect() used to do { ...result, edge }, which would silently strip the methods off a class. It now calls decision.withEdge(edge), and there's a test that would have caught the spread.

#731 — characteristics

rateLimit({ keyBy }) was the only way to change what a rule keyed on, and it was per-rule. Everything else was IP-only — the wrong subject for an authenticated API, and the wrong subject for us specifically, since the actor model exists precisely because IP is not identity.

const wd = new WebDecoy({
  characteristics: [(ctx) => ctx.headers['x-api-key']],
  rules: [rateLimit({ max: 100, window: 60 })],
});

A rule's own keyBy still wins. An absent characteristic falls back to the IP, not to an empty component — otherwise every unauthenticated request shares one bucket, so a limit meant for one tenant takes out anonymous traffic site-wide, and it's invisible until it happens. A characteristic that throws is treated the same way.

Decision caching

Deliberately narrow — server-derived DENY and CHALLENGE only:

  • ALLOW is never cached. That's how a client that has since started misbehaving keeps sailing through, and it saves the cheap request — a low-risk one already returns without calling out.
  • Rule outcomes are never cached. A rate limiter has to see every request to advance its window, and a cached tripwire hit would stop the violation being reported.

Bounded at 10k entries, oldest-first eviction, refreshed on overwrite so a repeatedly-denied key isn't evicted ahead of one nothing has touched.

Verification

21 new tests, 327 total, all passing. no-explicit-any budgets drop: express 14→12, nextjs 5→3, fastify 2→0. Build, lint and check:edge green.

protect() returned { allowed, detection } and the adapters typed the value
they handed to onBlocked as `any`, so integrating meant destructuring a
blob and string-matching to find out which rule fired. Three things the
SDK already knew had nowhere to go:

- Which rules ran. The engine collapsed to one deciding rule plus a
  violations array, so a filter rule that never ran for want of enrichment
  was indistinguishable from one that ran and passed. Both reported ALLOW.
  Every rule now appears in results[] with RUN / DRY_RUN / NOT_RUN /
  CACHED, and a dry-run rule that matched reports DENY -- what it WOULD
  have done is the reason you turned it on.

- "Challenge this one." We ship a proof-of-work captcha and the decision
  type could not express it, so it was reachable only by hand.

- A stable id. 'rule_' + Date.now() is not unique under concurrency and
  correlates with nothing.

characteristics answers a separate question the SDK had also hard-coded:
rate limits keyed on IP, which is the wrong subject for an authenticated
API and the wrong subject for us specifically, since the actor model
exists because IP is not identity. An absent characteristic falls back to
the IP rather than keying under empty -- otherwise one tenant's limit
takes out all anonymous traffic, invisibly.

Decision caching is deliberately narrow: server-derived DENY and CHALLENGE
only. Caching ALLOW is how a client that has since started misbehaving
keeps sailing through, and rule outcomes must not be cached because a rate
limiter has to see every request.

allowed is unchanged, including failing open on error. 327 tests pass, and
the any budgets drop (fastify to zero).

Closes WebDecoy/app#730
Closes WebDecoy/app#731
@cport1
cport1 merged commit 63b2f97 into main Aug 22, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant