feat(cli): honour trustedProducts from the local product config - #702
Merged
filvecchiato merged 2 commits intoSep 10, 2026
Conversation
A product under development has nothing on chain, so every cross-product call is refused and the flows a partner integration exists for cannot be exercised at all. `truapi-host --product-config` reads the same file the publisher reads, takes the trustedProducts a developer already wrote there, and seeds it into the manifest cache the core fills from dotNS. This is the manifest path, not a way around it: the core resolves the grant through the code it always runs, and a scope it does not honour is refused here exactly as it would be on chain. Only the document's origin differs, so the host prints what it applied and says it was never published. Repeating the flag serves a grant between two products, which is what the tests do: peopl.paseo grants dim2.paseo the storage scope, dim2.paseo reads a value peopl.paseo wrote, and the read goes through wire frames against the real CLI platform. That last part is the half a stub cannot cover — a host keying storage off the product that asked rather than the owner in the key returns nothing, and the grant silently does nothing.
`make e2e-cross-product-storage` runs five phases against the real binary, driving the @parity/truapi client over the frame protocol. peopl.paseo writes its own storage; dim2.paseo reads it because peopl.paseo's product config names it; stash.paseo reads the same key and is refused; a product that published nothing is refused the same way, so the call cannot be used to find out which products exist; and dim2.paseo reads once more at the end, so a refusal in the middle cannot be the value having gone. Each phase is its own host process. They share a base path, so the value a read returns was written by a process that has already exited, which is what makes this cross-product rather than cross-connection. The fixtures are ordinary local product configs, so they double as an example of the file. dim2.paseo's grants nothing: grants point inward, and reading peopl.paseo needs only peopl.paseo's config.
Collaborator
Author
|
@lore-bot-app review |
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
1 participant
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.
Closes #524. Based on
rfc/granted-scopes(#454), notmain— the manifest cache it seeds only exists there.What
truapi-host --product-config <path>reads theLocalProductConfigthe publisher reads (docs/rfcs/product-manifest.md), takes itstrustedProducts, and seeds the manifest cache the core would otherwise fill from dotNS. Repeat the flag to serve a grant between two products.Against #524's requirements:
trustedProductsfrom the local manifest config and applies it for the run. Same field, same shape, same file the publisher will read.manifest_grants_scope.Tests
peopl.paseograntsdim2.paseothestoragescope;dim2.paseoreads a valuepeopl.paseowrote. The read goes through real wire frames into aSigningHostRuntimeon the realCliPlatform— which is the half a stub cannot cover. A host that keys storage off the product that asked, rather than the owner encoded in the key, returns nothing and the grant silently does nothing.Also covered: an ungranted product refused, and a product with no config refused identically, so the local path keeps the uniform refusal the RFC requires.
New public API
One function on
truapi-server,encode_cached_root_manifest. The alternative was hand-encoding the cache's SCALE shape in the CLI, which #454 just changed once already.Not addressed
The grant expires with the cache lifetime. A host outliving it starts refusing grants the developer can still see in their own config; the doc on
applysays callers should re-seed on the same period, and nothing does that yet.