Skip to content

fix(policy): let an account DENY win over an earlier override ALLOW - #111

Closed
bookingminds wants to merge 2 commits into
tetherto:mainfrom
bookingminds:fix/override-allow-account-deny
Closed

bookingminds wants to merge 2 commits into
tetherto:mainfrom
bookingminds:fix/override-allow-account-deny

Conversation

@bookingminds

Copy link
Copy Markdown

Description

A matching override_broader_scope ALLOW returned ALLOW_FINAL at once, so an account-scope DENY registered after it was never evaluated.

evalGroup now remembers the first matching override and keeps scanning the account group:

  • A DENY in the group still wins.
  • The override still skips project-scope evaluation.
  • The first matching override is still the one reported.

The override_broader_scope JSDoc no longer says that the first override wins against later DENYs.

Motivation and Context

The README says DENY still wins on the same account. Before this change, the same two account rules gave BLOCK or ALLOW depending on registration order.

I also ran a differential check of evaluate() against those semantics over random policy sets. The sets mix ALLOW and DENY, wildcard and array operations, override flags, and passing, failing or throwing conditions. Each case also runs with the registration order reversed.

  • On main, 494 of 20,000 cases differ from the documented outcome. In 710 cases the outcome changes when the registration order is reversed.
  • On this branch both counts are 0, over 40,000 cases with two seeds.

The script is not part of this PR. I can add it as a test if that is useful.

Related Issue

Closes #100

Type of change

  • Bug fix (non-breaking change which fixes an issue)

Verification

  • npm ci, npm test (184 passed) and npm run lint pass.
  • The new test.each covers both registration orders through the public API. It fails on main for the override-first order.
  • In types/src/policy/policy-engine.d.ts, only the changed JSDoc line is updated. A full npm run build:types on my machine rewrote 13 unrelated declaration files, so I left those out.

Prepared with Claude Code. I reproduced the bug and ran the tests and lint.

A matching override_broader_scope ALLOW returned ALLOW_FINAL at once, so
an account-scope DENY registered after it was never evaluated. The same
two rules gave BLOCK or ALLOW depending on registration order.

Keep scanning the account group after a matching override. A DENY in the
group still wins; the override only skips project-scope evaluation. The
first matching override is still the one reported.

Closes tetherto#100

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
After an override ALLOW is recorded, only a later DENY can change the result. Other rules still ran their conditions, which added their latency and fired stateful conditions such as rate-limit counters. Skip them before their conditions run. Raised by @AlonzoRicardo in review of tetherto#119.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@bookingminds

Copy link
Copy Markdown
Author

Closing this one: the same fix landed in #119, merged on 15 October, which closed #100. Thanks @Boka44 for merging it and @AlonzoRicardo for the review.

For #120: the protocol simulate test in bookingminds/wdk@600ccf3 still applies cleanly on main, if it helps to close that one.

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.

override_broader_scope ALLOW skips a later account-scope DENY

1 participant