Repository navigation
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.
Description
Sessions that River creates from Slack are owned by River's service identity (
minerva.river@shopify.com), not by the person who asked. So Prime greets "Minerva", and the requester can't use owner-only features such as Local Agents.This lets a configured service identity create a session for someone else:
SESSION_DELEGATORSlists the trusted callers.SESSION_DELEGATE_EMAIL_HEADERnames the header that says who the session is for. Delegation is off unless both are set.user. Every other caller, or a delegator that names nobody, is unchanged.POST /api/sessionsonly. On every other request the delegator keeps its own identity, so it never gets the owner's privileges, such as minting remote-environment tokens.Why the header can be trusted
The header has to be set by infrastructure the delegator can't control. For River, that's Aquifer's credentials proxy: its
delegation_attributionrule deletes any value the sandbox sent, then setsX-Shopify-Forward-User-Emailto the person driving that River session, using Aquifer's own records. World's Usenet already trusts the same mechanism ("Delegated identity" inareas/tools/usenet/docs/identity.md). Only the proxy holds River's login, so a request authenticated as River has always been through it. A person who sends the header with their own login is ignored.Rollout order matters: the proxy rule for Oasis has to be live before an instance sets these variables. Until then, River could set the header to any value itself.
Screenshots
N/A
How to test
pnpm --filter @tangent/server test: the newsrc/auth/identity.test.tscovers a delegator naming a person, non-delegators, missing or invalid or multiple values, the off-by-default config, and anonymous callers.x-forwarded-email: minerva.river@shopify.com.SESSION_DELEGATORS=minerva.river@shopify.comandSESSION_DELEGATE_EMAIL_HEADER=x-shopify-forward-user-email, ask River in Slack to start a Tangent session, and check that the session'suseris you and Prime greets you.Notes
delegation_attributionforoasis-staging.shopify.io) is agreed with the Aquifer team.