Repository navigation
Let a consent prompt run in the phase the publisher chooses - #1362
Open
jwrosewell wants to merge 29 commits into
Open
jwrosewell wants to merge 29 commits into
jwrosewell wants to merge 29 commits into
Conversation
`cmp.inmobi`, `cmp.didomi` and `cmp.sourcepoint` declare both phases, so an entry of either phase may name them. What a prompt writes is the same for every reader, so the fetch phase stores it in the page every reader is served from, which is what a generated configuration places, and the serve phase writes it on each reader's copy for a publisher who wants the stored page without it. Selecting the InMobi module with no entry of either phase naming it is still refused. The stock list keeps each prompt's row in the fetch phase, which is the phase `ts audit generate` writes, and its test allows a middleware that runs in several phases to be listed in one of them, checking that what is listed for a phase is registered for it and that everything registered is listed somewhere.
The InMobi guide places the prompt by an entry of either phase and says what each phase does with it, the configuration guide's middleware table says the same for every consent management platform, and the changelog records the change.
# Conflicts: # crates/cmp/inmobi/src/lib.rs # docs/guide/integrations/inmobi.md
A serve middleware's head markup is written after every fetch middleware's, so a prompt placed in the serve phase comes after a vendor's tag a fetch entry writes. The guide now says to place the prompt in the fetch phase wherever a fetch middleware writes a vendor's tag. The Sourcepoint page change's doc names both phases, as Didomi's does.
This was referenced Oct 15, 2026
A serve middleware's head markup is written after every fetch middleware's, so a prompt named in [[serve]] followed any vendor's tag the [[fetch]] entry for the same page wrote into the head. The InMobi module now refuses, when the service starts and in ts config validate, a [[serve]] entry naming cmp.inmobi for a page whose [[fetch]] entry names another middleware. The module cannot tell which middleware write a vendor's tag, so it refuses any. Pages are compared by the entries each phase gives them, so entries under paths that never meet are accepted.
A prompt named in both a [[fetch]] and a [[serve]] entry for the same page was written on it twice, loader included. The InMobi module now refuses that when the service starts and in ts config validate, and accepts each phase naming it for pages the other never reaches. The refusal of a serve prompt after fetch middleware now says that the serve phase writes after what the fetch phase writes ahead of the script bundle, since fetch markup written after the bundle lands after a serve prompt.
No test ran cmp.inmobi, cmp.didomi or cmp.sourcepoint from a [[serve]] entry through the registry's check or a page. Each crate now builds the registry with its recorded page's settings moved from [[fetch]] to [[serve]] and checks that the reader receives the recorded page, which a page with no other middleware gets from either phase.
The Sourcepoint page change became a struct that holds its template key and is built with `PageChange::new`, so the test that reads its phases builds it the same way, as the registration and the other tests do.
This was referenced Oct 17, 2026
This branch has not been deployed
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
Changes
crates/cmp/inmobicrates/cmp/didomicrates/cmp/sourcepointdocs/guidecrates/trusted-server-modules/srcCHANGELOG.mdCloses
Closes #1279
Spec
Spec: consent-prompt-phases
Test plan
CI on this pull request at 45df894 passed all 32 checks.
cargo test-fastly && cargo test-axumcargo clippy-fastly && cargo clippy-axumcargo fmt --all -- --checkcd crates/trusted-server-js/lib && npx vitest runcd crates/trusted-server-js/lib && npm run formatcd docs && npm run formatcargo build --package trusted-server-adapter-fastly --release --target wasm32-wasip1fastly compute serveChecklist
unwrap()in production code (clippy deniesunwrap_usedin CI)logmacros as AGENTS.md asks (notprintln!)Stacks on the sellers module (#1361).
What this pull request does
cmp.inmobi,cmp.didomiandcmp.sourcepointmay be named in a[[fetch]]or a[[serve]]entry. Each ran in the fetch phase alone, and an entry of the other phase naming one was refused when the settings loaded. Osano is not changed, because it changes no page and so has no middleware.A serve middleware's head markup is written straight before the script bundle, after every fetch middleware's. So a prompt placed in
[[serve]]comes after a vendor's tag a[[fetch]]entry writes, and[[serve]] middleware = ["cmp.inmobi"]with[[fetch]] middleware = ["tag.google-tag-manager"]puts Tag Manager ahead of the prompt. The InMobi guide now says to place the prompt in[[fetch]]wherever a fetch middleware writes a vendor's tag.Why
What a consent prompt writes is the same for every reader, so the fetch phase stores it in the page every reader is served from, and that is the phase
ts audit generateplaces it in. A publisher who wants the stored page without it, so that one stored copy can serve readers with and without the prompt, places it in the serve phase instead, where it is written on each reader's copy. Which phase is the publisher's choice, and the modules no longer make it for them.What is checked
How it was verified
Not exercised: no page has been served through an adapter with a prompt placed in the serve phase. Each module's registration is checked for both phases, and the stock list's registry for its listing.
References #1279.