Callers and users
Who called a tool, the end user it runs for and the outside client, as the host sets them, and how a service vouches for a user of its own.
use berm_lang::Caller;
match berm_lang::caller()? {
Some(Caller::Outside(account)) => { /* an account the host authenticated */ }
Some(Caller::Service(name)) => { /* another service, through berm_lang::call */ }
None => { /* the host: a wake, a cron, a Stripe event, or an anonymous call */ }
}caller()is set by the host, never by the caller. In a nested call it is the full deployment address of the service that made it, such asalice/dashboard. A tool that limits its callers checks it.- Which callers reach a tool at all is
accessin its[tools]table. See Access. user()is the end user the call runs for,User { issuer, subject }: the identity provider or service that vouched for them, and who they are to it. It is carried into every nested call.vouch(subject)runs the rest of the call, and every call it makes, forsubject, with the service as the issuer. It is refused for an empty subject and in a call that already runs for a user.client()is an opaque key naming the outside client for one day, orNonewhen the host supplied none. It is carried into every nested call.client_ip()is the outside client's IPv4 or IPv6 address, orNonewhen the host supplied none. It is carried into every nested call. Cloud supplies the address for browser-app calls; the local host accepts an unchecked address in the caller header'sclientfield.deny(message)makes anErrorthat fails the call as refusing its caller.
Caller and user identities do not partition storage. All callers of a deployment share its database and keyspace. A multi-user service must scope its keys and SQL queries to the appropriate authenticated identity; see Data. Local --caller identities are unchecked.