Release 2.11.0: pre-payment verification path on conditional gates - #143
Merged
Merged
Conversation
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.
Summary
Release 2.11.0: the pre-payment verification path now works on the conditional gate adapters too, not only on
Checkout. Worked with Varun.2.10.0 let an identity-gated
CheckoutanswerX-Verification-Session: createwith the session 403. A merchant mounting the gate itself with a conditional adapter variant still ran the gate only on a payment credential. This release makes the rule one shared predicate:should_run_conditional_gate(request_or_headers): a payment credential, orrequests_verification_session(...)(the header set tocreate, case-insensitive, with no identity and no payment). Every conditional variant uses it: aiohttp, Django, FastAPI, Flask, the ASGI middleware and Sanic.has_identity_header(...): operator token, wallet address, or a non-emptyAgent-Identity.build_identity_bootstrap(): theidentity_bootstrap402 block.Checkoutnow builds its block with it, and a merchant building its own 402 passes it inbuild_402_body'sextra.VERIFICATION_SESSION_HEADER/VERIFICATION_SESSION_VALUEmove toagentscore_commerce.payment.payment_header, still exported from the top level.Checkoutdrops its private copies of these checks. The README's hand-rolled conditional example andCLAUDE.mddescribe the shared predicate.Type of change
Public API
Additive:
should_run_conditional_gate,requests_verification_session,has_identity_header,VERIFICATION_SESSION_VALUE(top level andagentscore_commerce.payment), andbuild_identity_bootstrap(top level andagentscore_commerce.challenge).VERIFICATION_SESSION_HEADERkeeps its top-level export. Behavior change on conditional variants: a request carryingX-Verification-Session: createand no identity or payment now runs the gate; every other request behaves as before.Test plan
tests/test_verification_session.py: header handling, suppression by each identity and payment header, emptyAgent-Identity, the predicate's truth table, and the builder.tests/test_fastapi.py: the header with no identity runs the gate and returns the session 403 without calling assess; the header with an operator token flows through with neither assess nor session calls. With the adapter pointed back athas_payment_header, the first fails and the second passes.Checklist