Permission scopes

The problem, on xataworks.ca

A permission answer belongs to a site, and a site is a host name: xataworks.ca. Every example in this guide is served from that one host, so allowing the hello example’s tools allows the Notes example’s too. For a guide that is harmless. For a service where app.example.com/t/acme and app.example.com/t/globex are two different customers, it is not what anyone meant.

A rule per host

A permission scope rule names a host and the leading part of the path that tells one context from another. One rule per line, in priority order; the first rule that matches a page wins:

app.example.com = /t/{tenant}
*.example.org   = /projects/*

• The host is an exact name (app.example.com), a name and all its subdomains (*.example.org, which also matches example.org itself), or * for every host.
• In the path, a literal segment such as t must match, ignoring case.
• {name} or * matches one segment, whatever it is, and that segment becomes part of the scope.
• A rule covers everything below its path: /t/{tenant} matches /t/acme/invoices/17 as well as /t/acme.

With the first rule, a page at app.example.com/t/acme/invoices/17 is in the scope app.example.com/t/acme, and every question, answer and refusal for it names that scope. A page that fits no rule — the login page at app.example.com/login, say — is granted for the whole host, as if there were no rule. Rules only ever narrow.

The worked rule

On xataworks.ca, where the examples live, one rule gives every example its own answers:

xataworks.ca = /developers/examples/{app}

With that rule stored, opening the hello example and asking the agent to use it produces the same question as before — about a narrower site:

Where rules live

• For every chat: Preferences › Browser › Permission scopes, a box with one rule per line.
• For one agent’s chats: the agent’s Browser tab, Permission scopes (blank = inherit). Leaving it blank uses the Preferences rules.

The person sets these, not your page: a site cannot widen or narrow its own permissions. What you can do is make your paths scope-friendly — keep the tenant, workspace or project in a fixed leading position — and tell your users the one-line rule that fits your application.

For your own multi-tenant application

If tenants are a path segment, the rule is the shape above: app.example.com = /t/{tenant}. If they are subdomains — acme.example.com, globex.example.com — you need no rule at all: each subdomain is already its own site.

The same scope appears wherever a site does: in the questions, in Permissions for this chat, in the shield’s heading, and in an agent’s declared web permissions, where a site can be written with its path, as in jira.example.com/tenant-a.