docs: clarify that lock contexts require OidcFederationStrategy#59
Merged
Conversation
Follow-up to #57, from review feedback on the v2 port (#56). The client setup blocks configure `authStrategy`, but the examples below them import an already-built client, so a reader skimming the encrypt and decrypt snippets sees `.withLockContext()` with no strategy in view and could reasonably conclude the claim binding stands alone. - Warn that OidcFederationStrategy is the only strategy supporting lock contexts. AccessKeyStrategy authenticates as the service, so there is no end-user identity for ZeroKMS to resolve the claim against. - State that the examples depend on the authStrategy-configured client. - Explain that `_` in the dashboard OIDC providers URL is the selected workspace. Dropped the "AccessKeyStrategy is also re-exported" aside from identity.mdx: naming it in a lock-context section was what invited the confusion.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
Follow-up to #57, applying review feedback left on the v2 port (#56, now merged).
What the reviewer caught
The client setup blocks do configure
authStrategy. But the encrypt/decrypt examples below them import an already-built client:Someone skimming those snippets sees
.withLockContext()with no strategy anywhere in view, and could reasonably conclude the claim binding works on its own. It doesn't. WithoutOidcFederationStrategy, the client authenticates as your service, and ZeroKMS has no end-user identity to resolve the claim against.Changes
Applied to
encryption/identity.mdxandencryption/supabase.mdx:A warn callout.
OidcFederationStrategyis the only strategy that supports lock contexts.AccessKeyStrategydoes not, and the callout says why. Confirmed againstclient.d.ts: "Lock context is an additional capability layered on top ofOidcFederationStrategy: it requires that strategy, butOidcFederationStrategydoes not require lock context."The examples now state their dependency on the
authStrategy-configured client, rather than leaving it implicit in an import.The dashboard link explains the
_, which resolves to whichever workspace you have selected.Also dropped the "
AccessKeyStrategyis also re-exported" aside fromidentity.mdx. Naming it in a lock-context section was what invited the confusion.kms/oidc.mdxuses the same_URL but already reads "Go to your workspace in the Dashboard", so it needs no change.Checks
bun run buildpasses, 589 pages.