fix: map unified allow/block to valid Vercel actions instead of passing through - #280
Merged
Merged
Conversation
…ng through
unifiedToVercel used `rule.action.type` directly with no mapping at all,
so a rule with action: {type: 'allow'} or {type: 'block'} passed
doorman's own local validation (against the wider 8-value unified
ActionType) and was dispatched to Vercel's real API carrying a
mitigate.action value Vercel's own native schema (log, deny, challenge,
bypass, rate_limit, redirect -- 6 values, no allow/block) says is
invalid.
Added VercelActionType (types/vercel.ts), Vercel's actual native action
vocabulary -- previously VercelMitigationAction.action reused the wider
unified ActionType directly, so TypeScript never caught the mismatch
either. This matches the pattern CloudflareAction/FastlyRequestActionType
already establish: a dedicated native type per provider, not the shared
unified one. Narrowing this type surfaced exactly the one call site that
needed fixing.
mapUnifiedActionToVercel maps allow -> bypass (skip further mitigation,
Vercel's closest equivalent to letting a request through) and block ->
deny (Vercel's actual block-like action); the other 6 unified action
types are already valid Vercel actions and pass through unchanged.
Every unified ActionType has a real Vercel action to land on, so this
never needs to warn or drop a condition, unlike #261's operator fix.
|
🎉 This PR is included in version 3.15.4 🎉 The release is available on: Your semantic-release bot 📦🚀 |
gfargo
added a commit
that referenced
this pull request
Aug 25, 2026
…) are fixed (#282) ne/not_contains/not_in and allow/block were documented as known-bugs to avoid on Vercel; both are now correctly handled (neg-flag composition and bypass/deny remapping respectively, per #279/#280). gt/ge/lt/le remain a genuine platform gap -- Vercel has no numeric-comparison operator at all -- but that's now a documented, safe drop-with-warning rather than a silent bug to avoid.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #262
Summary
unifiedToVercelusedrule.action.typedirectly with no mapping at all — so a rule withaction: {type: 'allow'}or{type: 'block'}passed doorman's own local validation (against the wider 8-value unifiedActionType) and was dispatched to Vercel's real API carrying amitigate.actionvalue Vercel's own native schema (log, deny, challenge, bypass, rate_limit, redirect— 6 values, noallow/block) says is invalid.Added
VercelActionType(types/vercel.ts), Vercel's actual native action vocabulary — previouslyVercelMitigationAction.actionreused the wider unifiedActionTypedirectly, so TypeScript never caught the mismatch either. This matches the patternCloudflareAction/FastlyRequestActionTypealready establish: a dedicated native type per provider, not the shared unified one (confirmed both other providers already follow this; Vercel was the outlier). Narrowing this type surfaced exactly the one call site that needed fixing — nothing else broke.mapUnifiedActionToVercelmapsallow→bypass(skip further mitigation — Vercel's closest equivalent to letting a request through) andblock→deny(Vercel's actual block-like action); the other 6 unified action types are already valid Vercel actions and pass through unchanged. Every unifiedActionTypehas a real Vercel action to land on, so — unlike #261's operator fix — this never needs to warn or drop a condition.Test plan
allow→bypass,block→deny, and all 6 already-native actions passing through unchangedallow/blockmapping values while keeping the function wired up) — each confirmed the right tests fail with a clear message, restoredpnpm compile && pnpm test && pnpm lintall pass (1781 tests, 0 lint errors)