Found while implementing #13608 (re-evaluating publicSharing.eligibility at redemption). Adjacent, and deliberately not carried by that card's PR — its ruling scopes the change to the eligibility predicate.
What the source says
ShareLinkService.getPolicy() (packages/plugins/plugin-sharing/src/share-link-service.ts) returns an EMPTY policy whenever the object's publicSharing block is absent or enabled !== true:
const raw = schema?.publicSharing;
if (!raw || raw.enabled !== true) {
return { enabled: false, allowedAudiences: [], allowedPermissions: [], redactFields: [] };
}
resolveToken() then computes the served redaction set as policy.redactFields union the per-link redact_fields. Two consequences for links that were minted while the object WAS opted in, and are redeemed after it was opted out:
- The links keep resolving. Nothing in the redemption path reads
policy.enabled; the opt-in is a mint-time check only (createLink refuses with SHARING_NOT_ENABLED). So revoking the object-level opt-in does not stop anonymous serving of the tokens already handed out. - The object's default redactions stop applying — the fail-OPEN direction. With
enabled:false the policy's redactFields is [], so a link that was serving a record with, say, owner_id stripped starts serving owner_id. Turning the feature OFF makes the endpoint serve MORE data than it did while it was on.
Read from source on origin/main; stated as a source reading, not as a behavioural measurement — no test was run for it, because the card that surfaced it is scoped elsewhere.
Why it is a separate card
#13608's ruling is specifically about the eligibility predicate, and its fix re-evaluates that predicate only. What enabled:false should mean for an already-minted token is a policy question that card did not answer, and there are at least two defensible answers: treat de-opt-in as a standing policy the way eligibility now is (links die), or treat it as an authoring-surface switch that stops NEW mints only (links live, but then item 2 above is still a plain bug and the object's redactFields must keep applying). Item 2 looks wrong under either answer.
Suggested shape
Whatever is decided for item 1, item 2 wants the redaction set read from the object's declared block regardless of enabled, so that switching the feature off can never widen what an existing token serves.
Related: #13608 (the eligibility half, already ruled and implemented).
Generated by Claude Code
Generated by Claude Code
Found while implementing #13608 (re-evaluating
publicSharing.eligibilityat redemption). Adjacent, and deliberately not carried by that card's PR — its ruling scopes the change to theeligibilitypredicate.What the source says
ShareLinkService.getPolicy()(packages/plugins/plugin-sharing/src/share-link-service.ts) returns an EMPTY policy whenever the object'spublicSharingblock is absent orenabled !== true:resolveToken()then computes the served redaction set aspolicy.redactFieldsunion the per-linkredact_fields. Two consequences for links that were minted while the object WAS opted in, and are redeemed after it was opted out:policy.enabled; the opt-in is a mint-time check only (createLinkrefuses withSHARING_NOT_ENABLED). So revoking the object-level opt-in does not stop anonymous serving of the tokens already handed out.enabled:falsethe policy'sredactFieldsis[], so a link that was serving a record with, say,owner_idstripped starts servingowner_id. Turning the feature OFF makes the endpoint serve MORE data than it did while it was on.Read from source on
origin/main; stated as a source reading, not as a behavioural measurement — no test was run for it, because the card that surfaced it is scoped elsewhere.Why it is a separate card
#13608's ruling is specifically about the
eligibilitypredicate, and its fix re-evaluates that predicate only. Whatenabled:falseshould mean for an already-minted token is a policy question that card did not answer, and there are at least two defensible answers: treat de-opt-in as a standing policy the way eligibility now is (links die), or treat it as an authoring-surface switch that stops NEW mints only (links live, but then item 2 above is still a plain bug and the object'sredactFieldsmust keep applying). Item 2 looks wrong under either answer.Suggested shape
Whatever is decided for item 1, item 2 wants the redaction set read from the object's declared block regardless of
enabled, so that switching the feature off can never widen what an existing token serves.Related: #13608 (the eligibility half, already ruled and implemented).
Generated by Claude Code
Generated by Claude Code